[Cryptography Team] Re: SSL Certificate Validation

[Robert Withers]

Thanks for the clarifications, Tim.  It makes much sense, now.

Robert

On Jan 26, 2007, at 4:50 PM, Cerebus wrote:

> On 1/25/07, Rob Withers <reefedjib at 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
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ 
> cryptography