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. 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. 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. 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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature