>>> Michael Ströder<[email protected]> schrieb am 01.11.2013 um 19:26 in Nachricht <[email protected]>: > Howard Chu wrote: >> Michael Ströder wrote: >>> BTW: >>> >>> In case of client certs the cert's subject-DN is the authc-DN which can be >>> directly used in authz-regexp which very much ties the mapping to subject-DN >>> conventions of the PKI. >>> >>> But in some cases it would be very handy to map a distinct client cert to a >>> authz-DN by issuer-DN/serial or even by fingerprint. One use-case is cert >>> pinning of client certs and revocation checking done off-line. >>> >>> Should I file an ITS for that? >> >> I would reject such an ITS. Cert-pinning is an issue for clients that have a >> very large collection of trusted CAs. The Admin Guide clearly states that >> servers should only trust a single CA - the CA that signed its own certs and >> the certs of its clients. In that case, no one else can issue a valid cert >> with the same subjectDN. > > Unfortunately it's not that easy: > > Consider a (somewhat broken) "official" CA, which you definitely cannot > avoid > or fix and which issues client certs with non-unique subject-DNs. In this > case > one has to choose a certain client cert e.g. by issuer-DN/serial for the > mapping.
CAs either accept the subject name in the certification request, or they deny it, but they never change it. > > Also consider that you want to off-load revocation checking of client certs > to > a external process for better performance. In this case you also need to > distinguish client certs by some more information than just a subject-DN. "you" is the process that handles CRLs. That process should be able to do it properly. > > Furthermore it's really not unusal to have several CAs which issue client > certs for different purposes. So IMHO it should be possible to map client > certs by a certain CA only to a certain subset of authz-DNs. That's also wrong: You don't have to observe the issuing CA, but the certificate's attributes, like "X509v3 Key Usage". > > Anyway I always felt that using directly the subject-DN is not consistent > with > the usual "<pattern>,cn=external,cn=auth" used for SASL/EXTERNAL. > > Other server implementations implement client cert to authz-DN mappings by > cert matching which is really handy in some cases. > > Ciao, Michael.
