On 1/25/07, Rob Withers reefedjib@yahoo.com wrote:
I am not currently parsing the certificate extensions, and discussion of the commonName vs the subjectAltName has always confused me. This would be something that could be worked on with X509.
Back when X.500 defined distinguished names, there wasn't a lot of thought about non-people being named in this way. X.509 adopted the X.500 naming scheme, but applied to people, services, devices, etc. Various kludges were added to DN to accommodate different protocol naming needs.
Eventually a light dawned and the subjectAltName extension was defined. The protocol specific names go in there (predefined types like rfc822Name, iPaddress, dNSName, etc.), leaving the subject DN for a human-readable names.
Also, subject DN is allowed to be empty, in which case the names *have* to be in subjectAltName. :)
I don't understand what you mean when you say "it's bad practice to put authorization data into an authentication instrument like a certificate".
Mostly that was aimed at Ron but I was at the airport posting from my N800 so I was being lazy.
I would think that once a certificate is authenticated, then it's identity (commonName or subjectAltName) could be used for authorization. At least the SSL spec speaks about it working this way.
Correct. However, the authZ decision should be made local to the service, *not* by the certificate issuer. IOW, the certificate or public key is your index into a local authorization database, and it's the information in that database that determines the cert holder's access rights.
-- Tim