[kmf-discuss] DN/subjectAltName mapping to username

[Nicolas Williams]

On Thu, Dec 20, 2007 at 04:54:19PM -0500, Wyllys Ingersoll wrote:
> Yes, I agree.  We need to figure out some sort of syntax for creating
> the mapping rules.  One that can easily be expressed and interpreted
> dynamically.  How does one derive a username from a standard SubjectName,
> for example? 

Whatever the syntax, the choices don't seem trivial.  There are too many
options, and it's not necessarily clear which ones we shouldn't bother
with (we'd need a lot of data on both, existing and planned PKI
deployments, as well as on CA software capabilities).

Here's a list of options that come to mind:

1)  CN from DN of certs validated to some trust anchor (which might, and
    probably should be the immediate issuing CA in all cases -- trust
    anchors are per-policy, not global, and mapping options should be
    also).

1a) Like (1) but with re-write rules like the ones in krb5.conf.

1b) CN from directoryName subjectAltName of certs validated to some
    trust anchor.  (I.e., like (1) but using DN SAN).

1c) Like (1b) but with re-write rules like the ones in krb5.conf.


2)  Local part of rfc822Name subjectAltName of certs validated to some
    trust anchor.

2a) Like (2) but with re-write rules like the ones in krb5.conf.


3)  Directory lookup based on cert DN, rfc822Name, directoryName SAN,
    and/or public key fingerprint.

3a) Local database lookup based on cert DN, rfc822Name, directoryName
    SAN, and/or public key fingerprint.


4)  Loadable plug-in SPI (for third party plug-ins) for mapping based on
    all other SAN types (otherName, ediPartyName and registeredID).


Of these I think the best options for a first round would be:

 - (2).  Certs can have multiple SANs, including multiple rfc822Name
   SANs, and it's not much to ask that CAs issue their users certs with
   an rfc822Name SAN that is of the form <username>@<domain>.

 - (3).  Folks deploying PKIs can be expected to have LDAP directories
   deployed as well.  Asking them to add an indexed attribute for
   mapping certs to user objects should be OK.

That's a pretty small and simple set of options to implement.


I'm down on these:

 - (4).  This is easy, but will anyone ever write such a plug-in and
   will anyone deploy a CA that includes the right kind of otherName?  I
   doubt it.

 - (1*).  I find it hard to believe that users are being issued certs
   with CN=<username>.  I also find it hard to believe that folks will
   be able to write reliable re-write rules for mapping DNs to
   usernames.

 - (3a).  Local databases can be useful, but for large scale deployments
   we need (3) before (3a).

 - (2a).  Re-write rules are difficult to get right, and depend on one
   sticking to strict naming conventions.  They may also be difficult to
   implement.

Nico
--