[foaf-protocols] looking back to 1988 for proof that cert existance in container => valid

peter williams home_pw at msn.com
Mon Mar 7 18:51:27 CET 2011


http://www.freepatentsonline.com/7434253.html

 

Let's have a more detailed look at the Microsoft patent around validation
agents doing cert->account mapping, and the patent's principal claim
(below). Perhaps this is more relevant to me than other implementations,
since it seems to address those special cases of webid, where the browser is
itself the foaf card document repository and card endpoint.

 

This is as in my own example of leveraging Opera browser and Operate Unite,
which enables the browser to be a client AND web server, both acting as a
"first computing device" responsible for sending certs, the hint AND the
mapping info (the foaf card) to the validation agent. I have to be careful
that the client cert contains all the "locator-information" for the foaf
card, in this case.

 

I have to be careful furthermore that there is nothing SSL specific about
the claims. It's all as valid for a client-cert based in https as a signed
SAML token or openid assertion.. or anything else that is essentially a
signed user claim, with cert in tow.

 

1.      An authentication method for authenticating a first computing device
to a second computing device, the authentication method comprising the first
computing device sending to the second computing device a certificate
identifying the first computing device to the second computing device, and
the second computing device at least attempting to map the certificate to an
account of the first computing device at an authentication server, the
method further comprising: 

 

sending a mapping extension indicator from the first computing device to the
second computing device separate from the sending of the certificate, the
mapping extension indicator specifying that the first computing device can
send to the second computing device mapping information to aid the second
computing device in locating the account of the first computing device at
the authentication server; 

 

acknowledging from the second computing device to the first computing device
that the second computing device can accept the mapping information separate
from the sent certificate pursuant to the received mapping extension
indicator; 

 

sending the mapping information from the first computing device to the
second computing device separate from the sending of the certificate; 

 

and locating, by the second computing device, the account of the first
computing device at the authentication server based on the sent mapping
information. 


The patent generalities go to on to describe the validation agent process
used in Windows, where the UPC plays the role of the URI used in webid
protocol. One sees then how the necessarily inband but non-cert-delivered
hint drives a "trust" locator protocol (my term), driving "acceptable" and
"acknowledged" hints about trust points in a federated graph. 

 

Within is hidden a pairwise trust negotiation protocol about third parties,
that is. 

.         "More particularly, for example, a LsaLogonUser( ) call may
include a hint. Name hints are passed to LsaLogonUser( ). For example, in a
message, a UNICODE_STRING DomainName, //OPTIONAL, if supplied, is used to
locate the forest; and a UNICODE_STRING UserName, //OPTIONAL, if supplied,
is used to locate the account. The domain name tells the client (e.g., the
local machine a user is logging into) which domain contains the mapped user
account. 

 

.         The caller is permitted to supply the user name to enable the
certificate be mapped to multiple user accounts. If the user name is
supplied, the KDC will use that to locate the user account, and verify that
the certificate is mapped to this account. 

 

.         If the user name hint is not supplied and the domain name is
supplied, the domain name is used by the Kerberos client to locate the KDC
for authentication, and KDC will map the certificate to a user account. It
is desirable to support client certificates that do not contain the
subjectAltName extension. Such certificates may be mapped to Active
Directory accounts. A generic and extensible solution is provided for the
certificate to account mapping problem.

.         If the certificate contains subjectAltName/UPN extension, KDC will
use that to map the client. In this case, the client certificate desirably
satisfies the NT_AUTH policy. If no user object is found based on the UPN,
the authentication should fail. 

 

.         If there is no UPN in the certificate, the KDC constructs the
"X509:<I><S>" AltSecID name to lookup. In this case, the client certificate
does not need to satisfy the NT_AUTH policy. 

NOTE ABOVE AND BELOW FOR DEDUCED NAMES

.         If there is no UPN in the certificate and no user object has been
located in the steps above, the client account may be looked up based on the
Distinguished Name of the subject, the KDC constructs the "X509:<S>"
AltSecID name to lookup. In this case, the client certificate desirably
satisfies the NT_AUTH policy. 

 

.         If there is no UPN in the certificate and no user object is
located in the steps above, the KDC uses the subject and serial number to
construct the "X509:<I><SR>" AltSecID name to lookup. In this case, the
client certificate does not need to satisfy the NT_AUTH policy. 

.         If there is no UPN in the certificate and no user object is
located, and the client certificate contains an SKI, the KDC constructs the
"X509:<SKI>" AltSecID name to lookup. In this case, the client certificate
does not need to satisfy the NT_AUTH policy. 

.         If there is no UPN in the certificate and no user object is
located in the steps above, the KDC constructs the "X509:<SHA1-PUKEY>"
AltSecID value to lookup. In this case, the client certificate does not need
to satisfy the NT_AUTH policy. 

.         If there is no UPN in the certificate and no user object is
located in the steps above, the client account is looked up based on the
SAN/822name, the KDC constructs the "X509:<RFC822>" AltSecID to lookup. In
this case, the client certificate desirably satisfies the NT_AUTH policy. 

 

.         Note that the above steps and criteria can be used alone, or in
any combination or sequence. Additional steps and criteria may be also be
used. Desirably, the first step or criteria that successfully locates an
account wins, and the search stops. But there may be a configuration error
if there are two mapping methods that map the same certificate to different
user accounts. 

.         Note if the client's certificate does not have a UPN and the
client's DN in the certificate matches with a user account's DN, but that
user account is not mapped, then the authentication should fail."

 

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of peter
williams
Sent: Monday, March 07, 2011 8:59 AM
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] looking back to 1988 for proof that cert
existance in container => valid

 

Looking at that United States Patent 7434253 patent, it would address
sending the webid in SNI or HTTP header.

 

Only when the webid claim is wholly "in the cert" are folks on safer
grounds. Only when the webid is a (self-contained" locator are folks on
safer grounds.

 

If the _resolver_ address FOR the webid URI is _deduced from_ the webid,
that deduction cannot leverage information from the client PC (e.g.
sessionIDs, or IP address, or anything else).That would a hint, too. For
example of such an indirect hint, an earlier cert in the client cert chain -
that is sent by the client PC - is such a hint.

 

It's a nasty patent for FOAF+SSL/webid world, whenever the server then maps
the URI to a user "account".

 

As always, its only nasty till it gets invalidated by prior art. This will
have to wait till money is flowing in the webid world, that pays for all
that kind of preparatory study and the litigation(s). I have the material
(being in this area for decades), but as always it needs organizing for the
kinds of arguments that lawyers make, when forcing or otherwise dealing with
infringement claims etc.

 

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Peter
Williams
Sent: Sunday, March 06, 2011 8:19 PM
To: kidehen at openlinksw.com; foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] looking back to 1988 for proof that cert
existance in container => valid

 

have to be careful though, as soon as one adds anything beyond what there is
strong prior art (lampson, and X.509 1988). Even adding https to the foaf
card server has to be able to claim its an instance of Lampson's logic (and
one has to do it completely, using an ephemeral ciphersuite or perhaps the
proxy cert).
 
Presumably, the proxy cert people, having been through IETF, have strong IP
analysis.
 
http://www.freepatentsonline.com/7434253.html
 
win2000 didnt allow client certs -> NT user account mapping to then delegate
(using windows tokens means). But... then, thats a decade ago. Id be
suprised if its true still (simply since delegation is now so much stronger,
a decade later) given the whole token mapping world, in which presentation
of a client cert via https can and doesn induce the IDP to issue a token,
within limited scope and assertions. Seems to be a standard part of ADFS v2.
 
Which makes me wonder, if one might go to the scripts directory of ADFS, for
certs and alter it so it pings against webid documents, rather than AD. Or,
rather, pings against Kingley service - which remotely tests if a named foaf
card bear a cert/pubkey.
 

  _____  

Date: Sun, 6 Mar 2011 21:48:53 -0500
From: kidehen at openlinksw.com
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] looking back to 1988 for proof that cert
existance in container => valid

On 3/6/11 12:00 AM, peter williams wrote: 

We can also see it here (albeit for 2011):

 

http://technet.microsoft.com/en-us/library/cc755292.aspx

 

Semantically, its richer than merely testing for mere existence of cert in
container. There is also a match and find rule, mapping the cert (once
matched) onto an account field(s) found in the same directory entry.


Yes, and I expect WebID protocol implementers to have the freedom to expand
beyond WebID basics. In short, basic WebID is the minimum interop point,
other features can be used to enhance the trust semantics on a per
implementation basis. 

Anyway, that's what we've also sought to do, this is why we already to the
account dance via OAuth :-)

 

Folks we really understand directory 1992 might be able to explain the
notion of sub-entries, which equate in some sense to #tagged graphs within a
foaf card, and have some interesting inheritcance and schema control models
in support.

 

Anyways , good news, since rarely does MSFT do something that is not on
solid IP grounds (i.e. well supported with modern IP, or the process/system
is just really ancient).


Yes. That's my experience of MSFT. Worked them in early '90s, and their tech
even earlier.

Kingsley

 

 
_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

 

-- 
 
Regards,
 
Kingsley Idehen       
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com <http://www.openlinksw.com/> 
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
 
 
 
 


_______________________________________________ foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110307/0defedee/attachment-0001.htm 


More information about the foaf-protocols mailing list