- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 02 Jan 2012 21:43:40 -0500
- To: public-xg-webid@w3.org
On 1/2/12 5:55 PM, Peter Williams wrote: > I learned DN theory the hard way (from reading the code of an infamous resolver) that then did authn and authz (using an ACL based (IBAC) model akin to what I see in WAC). And of course, we have the author of "Permis" on the team. > > > > Remember the Name in the subject of the Cert is more than a DN since it can contain AVAs that are not distinguished (and not part of the composite key). The only way to know which is which (and which was a human hint for DISPLAY) was to de-reference (and no resolver exists, any more). > > > > The number of folks who do this correctly these days is nil (since even though who could, dont). The correctness issue is irrelevant. The Names/DNs in certs subject don't point to Directory objects any more. As Henry uses them (and everyone else uses them, from Netscape;s quick and dirty coding of certs onwards), its just a bag of strings, with a tag on the front of each. Thats it. Yes, it doesn't have to be that way. Addresses resolve to resources (data object descriptors). Names identify data objects. Thus, we can use the DN correctly. That's ultimately the only way to achieve loose coupling of data object names and descriptor resources. You've already setup the basic showcase: 1. SPARQL URL as part of the combination of components in the DN (basically compound sense) -- this is how you also leverage the URL shortener without producing a broken description graph 2. URIs in SAN that are described by the SPARQL URL (which can be a CONSTRUCT rather than DESCRIBE query). The Certificate holds the claim: holder of this Certificate has a descriptor at an address. This descriptor is comprised of a description oriented directed graph where attribute=value or predicate=object pairs coalesce around one or more URIs in the certs. SAN, explicitly or implicitly (courtesy of inference context). > > > > About the only place I know that proper identity semantics are retained in X.509 is in the OTHER-NAME "UPC" SAN type, defined by Microsoft, where the formal semantics have to work properly (becuase its tied to the trust model of kerberos, anbd kerberos-protoected identity endpoints). But, such is not the web (being pure enterprise). Well what's good for the enterprise (local area network based Webs i.e., intranets) is also good for extranets and the Internet :-) > You only see it in advanced security, including SSL used in SIP phone registration (where digest auth over SSL needs to protect against MITM) so the secure RTP tunnels (a variatn of TLS record layer) is not falsey keyed by an spook, wanting to listen in to VOIP/SIP. > > > > Now, that was unfair of me, as I see US here trying to do "proper identity semantics" in X.509, with the URI form. Yes, this is the goal. Leverage URI abstraction and ride the X.509 standard. Naturally, we have to thread carefully re. goals of WebID spec., which is about making a simple base from which higher level innovation can blossom following successful bootstrap. > > > > > > > > > > > > > > > -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Received on Tuesday, 3 January 2012 02:46:33 UTC