[kmf-discuss] DN/subjectAltName mapping to username

[Huie-Ying Lee]

Nicolas Williams wrote:
> On Wed, Dec 19, 2007 at 02:28:39PM -0800, Huie-Ying Lee wrote:
>> 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.
> 
> Yup.  I think we should adopt all of these.
> 
>> 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.
> 

What I was trying to say is that there is an existent example that uses
subject name and others as mappers.   I didn't mean that SSH/X509 should
use the pam_pkcs11 code to do the job.  Sorry for any confusion that I
might have caused.

> While that will work, one of the nice things about being able to use
> certs in SSHv2 would be the ability to reduce the need for such
> configuration.
> 
> Also, we might as well allow the use of string representations of cert
> DNs and/or SANs in ~/.ssh/authorized_keys (still much better than using
> public keys).
> 
> We've been discussing this topic on the ssh i-team list within SWAN, at
> length.  The issue is not "what mappings can we envision" but that we
> know we'll need this feature in multiple places because this is a
> generic problem, not one all that specific to SSH.  So given that it's a
> generic problem we'd like a generic solution.
> 
> KMF strikes us as potentially the right place to implement these
> mapping schemes.  Alternatives are welcome (e.g., you could argue for a
> new library and, possibly, service, as the home for this feature).
> 
> Nico

Initially, I was not sure whether KMF is the right place for this when
Jan brought up the idea.  However, after thinking it over a little bit,
it makes more and more sense to me.   Adding a new library with
a new policy file will make things more complicate. Given that KMF supports
many kmf_get_cert_xxx() APIs already.  Adding kmf_map_cert_to_username()
shouldn't be too odd.

Huie-Ying