W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

RE: How To Handle WebIDs for (X)HTML based Claim Bearing Resources

From: Peter Williams <home_pw@msn.com>
Date: Mon, 2 Jan 2012 14:55:15 -0800
Message-ID: <SNT143-W64CAB19F7C0EAE216BE1FA92910@phx.gbl>
To: <kidehen@openlinksw.com>, "public-xg-webid@w3.org" <public-xg-webid@w3.org>

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.


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). 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.







Received on Monday, 2 January 2012 22:55:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC