[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