dn and san matching
cneberg at sandia.gov
Mon May 21 20:06:29 EDT 2007
I'm assuming the reg-exp is against the whole DN so you can match
against multiple components of the DN? Correct?
pkinit_dn_san_match = ||SUBJECT:^OU = CITI,OU=UMICH.*,ISSUER:.*EDU$
Should searching for a specific client EKU OID also be in the list? Some
CA vendors ship certificate pairs: encryption and signature and have
identical DN's and issuers the only difference between them will be EKU,
and normal key usage bits.
>>> Otherwise, we could change our rule and just return the first cert
that matches one of the rules. In that case, the admin should define
the rules from most-specific to least-specific.
First cert match seems OK, leaves it up to the admin to be specific
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Kevin Coffman
Sent: Monday, May 21, 2007 3:54 PM
To: MIT Kerberos Developers
Cc: pkinit at citi.umich.edu
Subject: dn and san matching
The intent here is to provide the ability for an administrator to
configure a machine such that "the" right certificate, among possibly
many on a smartcard, is chosen for pkinit without requiring the user to
My intent is to keep this as simple as possible, yet powerful enough.
Does this syntax look reasonable? Corrections or suggestions welcome!
(I'm trying to keep parens and quotes and other things out of the syntax
so I don't have to try to parse the regular expressions and worry about
things being escaped within them.)
pkinit_dn_san_match = [&& | ||] [SUBJECT:<reg-exp> | ISSUER:<reg-exp>
There can be multiple instances of this config option. Examples might
pkinit_dn_san_match = &&SUBJECT:.*foo.*ISSUER:.*bar.*
(This would match if Subject contains "foo" AND Issuer contains "bar")
pkinit_dn_san_match = ||SUBJECT:^OU = CITI,.*ISSUER:.*EDU$
(This would match if Subject begins with "OU = CITI," OR Issuer ends
pkinit_dn_san_match = SAN:.*@TEST.COM
(This would match if there is a San for realm TEST.COM)
If we intend to enforce our rule of failing in the case where we don't
narrow it down to a single certificate, then we'd have to test all the
rules with all the certs to see how many certs match. Otherwise, we
could change our rule and just return the first cert that matches one of
the rules. In that case, the admin should define the rules from
most-specific to least-specific. Opinions?
krbdev mailing list krbdev at mit.edu
More information about the krbdev