[kmf-discuss] DN/subjectAltName mapping to username

Huie-Ying Lee huie-ying.lee at sun.com
Wed Dec 19 14:28:39 PST 2007


Nicolas Williams wrote:
> On Wed, Dec 19, 2007 at 04:45:59PM -0500, Wyllys Ingersoll wrote:
>>> 	any thoughts on that?
>> I think the subjectAltName x509 extension (RFC3280 section 4.2.1.7) 
>> could serve this purpose.
> 
> Not by itself.  Many certs might have only DNs.  So we need a solution
> that can map certs to usernames by taking into account the DN and/or any
> available SANs, and/or directory lookups.
> 

To map a user login to a certificate, the pam_pkcs11 module from opensc.org
supports many mappers.   I have successfully tested the digest, cn (common name),
subject (subject field), pwent and LDAP mappers with the OpenSC/pam_pkcs11 module.

The OpenSC/pam_pkcs11 also supports openssh and krb mappers.  According to the
pam_pkc11 document, the openssh mapper will search certificate public key
in ${HOME}/.ssh/authorized_keys.  This sounds to me a nice fit for
the SSH/X509 project.

Huie-Ying






>> A certificate may have multiple names, including email addresses and
>> local definitions (could easily be the Unix Username, though that is
>> unlikely to be a wise choice since it is not bound to any particular
>> domain and would be insecure to use as a binding to particular users).
> 
> One pam_pkcs11 module can map e-mail address SANs to usernames by
> checking that the domain of the address is in some list and then
> removing the @domain part to produce a username (I'm simplifying here).
> 
> Kinda like krb5 auth rules in krb5.conf :)
> 
> But that works if a cert has such a SAN.  That same module can also just
> take the CN as the username.
> 
> Other approaches are possible (think gsscred(1M) + nameservice support,
> which it _used_ to have back before the removal of XFN).  We could also
> add new SANs, but we couldn't expect them to be used for a logn time :/
> 
> (I mention gsscred(1M) because this problem is generic, and if we ever
> implement the new GSS-API PKI mechanism, 'PKU2U', then we'll have this
> problem in our GSS stack also.)
> 
> Nico



More information about the kmf-discuss mailing list