<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText42109 dir=ltr>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>"I am not sure if it would be correct use of the X509 Alternative names field. So this would require more standardization work with the X509 community. But it shows a way where the two communities could meet. The advantage of having the id as part of the certificate is that this could add extra weight to the id, depending on the trust one gives the Certificate Authority that signed the Certificate. "</FONT></DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT face=Arial size=2>I'm the geek who over a decade ago had ISO put the URI field in the std set of extended name forms (after a previous round of 'lets argue endlessly in IETF about name forms so as to resist ISO standards, since the X.500 DN is clearly "evil" stuff whose provenance make them incompatible with DARPA's mission'). ISO said: Ok! here is every name form we can think of for use with certs. Fight it out, now; just stop whining! SAML later did the same thing, stuffing every key format it could think off into its standard, to address similar whining about that topic too.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>You are using the URI field correctly, from reading the blog. I had them specify it as a URI, not as a URL. Believe it or not, I actually understood the difference, back then (1995?) , though I had to explain it carefully to the ISO WG's Rapporteur. (Also thank VeriSign! The Rapporteur could not stand me - being an unwashed pleb - but wanted VeriSign's blessing on his ISO submission; so I leveraged the two impulses to get what I wanted...URIs as certified name forms, formally normalized in an international standard issued under international regulations - affecting both postal and telco authorities.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>You may well find that an alternative, equivalent but klutzy approach is what takes off though, in contrast. Folks may end up putting the URI in the CN component of the subject or issuer DN name. This is because its already delivered by mainstream SSL libraries to a gazillion webapps in the mainstream webapp platforms, unlike cert extensions. Even my own SPARQL/RDF server does so, given the client cert to my RDF-processing scripts. (*)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I would not count on too much support from the mainstream PKI community. They will simply hound you till you got back to using DNs, since there is a implicit trust model that goes with DNs that goes to the heart of PKI and CA doctrine. Just go around them, and use what the standard permits in URI support - or just apply the CN field as we did the SSL community (*). I made the effort (subversively) so SOMEONE would eventually move us beyond DNs in SSL client cert - and the angst DNs and name-based crypto-control model that comes with them. I'm hoping its #you!</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Peter.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(*) the semantics of the CN field are an naming-authority defined field, unlike all the other ISO-defined naming constructs for the F.500 series of public naming standards (abandoned). Many folks have attempted to define formal and consistent semantics of a "common name" - usually by interpreting the very term "common". However, there are none, by definition. Its up to the provisioning authority for said name to define them, of which there are supposed to be an infinite variety. Being a very carefully, formal methods entity, RSA Labs understood this, when they counseled clueless Netscape to use the CN for the "domain name wildcard" relying party controls in https.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(**) most libraries do now deliver the full cert to the webapp, too. But, folks generally cannot be bothered to apply openssl to parse it. But, some easy to implement but professionally-nasty string matching can typically find such as an URI extension field for a subject, without formally parsing the TLV tree. More klutz, but klutz has a habit of taking off.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV id=idSignature13494>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Story Henry<BR><B>Sent:</B> Mon 4/21/2008 8:07 AM<BR><B>To:</B> OpenID General<BR><B>Subject:</B> Re: [OpenID] OpenId sequence diagram<BR></FONT><BR></DIV></DIV>
<DIV><PRE style="WORD-WRAP: break-word">_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>