>> Michael Ströder<michael(a)stroeder.com> schrieb am
01.11.2013 um 19:26 in
Nachricht <5273F248.4030101(a)stroeder.com>:
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.