dn and san matching

[Ken Renard]

I like the idea of looking at specific EKUs (beyond digital  
signature) as well.

When you are matching a SAN, are you matching against a specific type  
of SAN or all types?

Thanks!

-Ken




On May 21, 2007, at 5:53 PM, Kevin Coffman wrote:

> 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 specify anything.
>
> 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>
> | SAN:<reg-exp>]...
>
> There can be multiple instances of this config option.  Examples  
> might be:
>
> 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
> with "EDU")
>
> 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?
>
> K.C.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev