Kyle Hamilton wrote, On 2009-03-21 16:51: > On Sat, Mar 21, 2009 at 4:32 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: >> On 03/22/2009 12:55 AM, Ian G: >>> Hmmm, well, many questions abound: why wasn't it done? where was >>> this discussed? Why didn't client certs just happen? Why are we >>> still using passwords? >>> >> Good question....it's because it's so much more convenient and >> everybody is doing it...but guess what, some thought leaders and some >> leading projects are working on having that changed. > > Because the means of configuration isn't easy on the server side.
That's largely up to the server's admin tools right? Some make it much easier than others. > Because it means having to manually put the certs that one wants to > allow to authenticate other certs in the server configuration > directories. Yes, the server needs to be configured to know which issuers it should trust as issuers for client certs. Putting those trusted issuer certs in a directory is actually one of the easier ways to do it. > (Note that various versions of TLS allow for sub-CAs to > be explicitly named in the ClientCertificateRequest, rather than their > roots. I am going to assume that Nelson knows more on this topic than > I do, because I've been wrong with which versions allowed for what.) There are client implementations that will only send a client cert if the issuer name in the client cert itself is one of the issuer names in the CertificateRequest message. These tend to be found in small devices like cell phones. With those, the CertificateRequest message must specify the immediate issuer of the client cert, and not a higher level root, unless that root is the immediate issuer. There are client implementations that will send a client cert if the name of any issuer in that client cert's chain is found in the CertificateRequest message. With those, the server can specify the names of intermediate CAs and/or roots, as it wishes. NSS is like that. I don't know of any implementation that requires that the issuer name sent in the CertificateRequest message must be a root. > Because the server is hard to configure to do CRLs and/or OCSP. > Because the CRL still needs to be fetched, usually as a cron job. Some NSS-based server products handle automatic periodic downloading of CRLs from the trusted client cert issuers. > Because the server still needs to maintain its own local database of > accepted/trusted users. But that's no different with SSL client auth than with name+password auth. Any way you do it, the server has to know who is authorized and who isn't and that info has to be stored somewhere somehow. > Because there's no guarantee that a Subject will remain the same > Subject, so there's no easy way to map a Subject to a local user. I'd say that, whether the subject name changes or not, there is typically a need to map cert subject names to local identities. Some server products have all that mapping built in and offer admin tools to ease that administration. > Because there's no guarantee that a Subject is the same as another > Subject based on CN or any other individual part of a Subject, so > there's no easy way to protect privacy using only portions of the > Subject. Well, if you accept all certs from all well known CAs as client certs, and allow your users to change CAs as they wish, then yes, that's true. In most corporate environments, there is just one CA that is used for issuing client certs (typically run in house) and they have an agreement with that CA which specifies a particular attribute in the subject name that will be used as the "short hand" identity, such as (say) employee number. But generalized cert mapping solves this. > The problem isn't just on the server side, it's not just on the client > side, it's also on the CA side. The CA/B forum should have brought > Server vendors into the mix, too, to explain their plights. Each server is likely to have its own definitions of all these things. There isn't one single schema that will satisfy everyone. That's true even outside of SSL client auth. Just look at OpenID. > -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
