RE: Certificate Triplify Challenge

 I just browsed through . Its wrong to assert folks were not thinking carefully about the SAN, and its role in naming. They are just using a precise, formal, unambiguous formal model of identity. Go outside that model, one enters the realm of the identity model of the "name form" - in this case URIs. if one uses the oid name-form Alternative, for example, its all EXTREMELY formaliaze (and ratified by national standards bodies), at full ISO formalist level. But one has to read the ISO standards (which I suspect most people commenting here have never done).

 

Any ambiguity is largely a function of the name-form (not the bucket ISO gave for N name-forms, post 2000). ISO said: you wanted a bucket: here it is. Go have fun. Mcirosoft in parpticular had lots of fun with UPNs/SPNs, in certs.

 

If you want to stick to Names/DNs and DirectoryNames, its all perfectly simple. The number of folks who know the distinction between Names (in certs), DNs in strong bind and secure operation audience controls, and DirectoryNames (distinguished from Names/DNs) is small. But, then, the standard has been dead in the internet for a decade, if not longer. Various bits of it remain alive, in the certs world (ad hoc, at best, awful for the most part; butchered for its format mostly); or ldap (which didnt carry over the X.500 access or chaining security model, and only really deals with DNs).

 

It gets more fun, if one wants to deal also with application entity Titles (for binding to titular names, at layer 7), distinguished from the PSAP (presentation service access point address). But, the number of folks who know what an AE is, let alone an AE title, is even smaller than that above. 

 

signed JSON will soon be with us. And, I can stuff it into my shiny new SSL engine, now in source. I dont have to wait for a browser, thanks to "mentalis" giving me SSL ( in source) in dotNet, over a socket. the javascript SSL clients have the same advantage too - not need to stick to just the PKI or PGP cert types.

Received on Thursday, 12 January 2012 00:35:23 UTC