[kmf-discuss] DN/subjectAltName mapping to username

[Massimiliano Pala]

Hi Jan,

I understand perfectly your problem. The issue here is that there is
not a universal identifier in certificates that can be used to `extract`
a userid from them - at least one that is guaranteed to be unique.

MY assumption is that certificates with the same DN (not only the Common
Name, but the full Subject Name) are issued to the same entity. This is
a reasonable assumption, but it depends on the CA policy - as always.
If you want to be sure about selecting a single certificate, use the
serial number instead of the DN; the Serial Number MUST be unique within
a CA (at least RFC-3280 compliant CAs).

A possible solution would be to use hashes from the certificate DN and
the CA identifier (that can be the hash of the CA's certificate or the
authorityKeyIdentifier if present in the certificate).

When we developed the ssl-ftp and ssl-telnet applications, we used a
configuration file where we specified the mapping in this way:

	H(DN)+CAFingerprint:userid

So that the mapping for the system userid was done by looking at this
file (which was also signed by the service manager).

This could also be applied to standard unix shadow files. Instead of
having the password, you could have the following:

	H(DN)+CAFingerprint

in the shadow file (or in any other field in the user's info, or
in a separate pkishadow- file). This means that the user can use only
one certificate to login into its own account, but it is not a very
big limitation after all.

To map multiple certificates to a single uid, you will have to permit
multiple entries for the same uid in the pkishadow file. This option
could let you have multiple users logging into a single account (is
this something that could be useful to explore ? Privacy ? Anonymity ?).

I'd be happy to help with the development of the idea if you need it :D

Later,
Max


Jan Pechanec wrote:
> On Wed, 19 Dec 2007, Massimiliano Pala wrote:
> 
>> Hi all,
> 
> 	hi Max, please honor existing cc; adding Nico back there.
>> * the easiest way (and more secure one) is to use the full DN + CA Identifier
>>  (or serial + CA identifier) to map a user to a certificate.
>>
>>  Benefit of this approach:
>>  - Easy to implement
>>  - Secure
>>  - Interoperable (these fields are required in X509 certs)
>>  - If the full DN is used, then no change is required when the user
>>    renews the certificate (more usable)
> 
> 	well, but how would you exactly map it? Will you use CN, 
> subjAltName, or something else, from *existing* certificate? The problem is 
> that there might be different certificates out there and what we need is to 
> get a username from them in a different ways.
> 
> 	so, in general, the question is not what we want to use as a 
> username but what different ways of getting a username from existing 
> certificates we can support.
> 
> 	cheers, Jan.
> 
>> * Another option would be to use some extensions within the presented
>>  certificate.
>>
>>  I think that the best candidate (and the most standard one) is the otherName
>>  extension. This extension should be used instead of the subjectAltName which,
>>  in many cases, contains the email address of the certificate owner, not an
>>  ID that is used for a specific purpose (e.g., logging in into a system).
>>
>>  Keep in mind, however, that the contents of the extensions are not guaranteed
>>  to be unique across different users - that means that they are not good
>> candidates
>>  (to me) for UIDs conversion.
>>
>>  Anyhow, I know that this approach could restrict the usage of this
>> `conversion'
>>  function only to those certificate that present that extension.
>>
>> * Third possibility is to tie a username on the system to the public key
>> presented.
>>  Therefore no matter of the contents of the certificate (e.g., DN or
>> extensions),
>>  who is the owner of that particular keypair is entitled to login into the
>> system
>>  by using a specific UID.
>>
>>  The drawback of this approach is that to login under different UIDs, the user
>> has
>>  to use different Keys, not only different certificates. This might be an
>> issue in
>>  the case of HW devices that can handle only one key (usually having multiple
>> certs
>>  for a single key is not an issue).
>>
>>  A benefit of this approach is that if the user renews the certificate (thus
>> keeps
>>  her the same key pair), the new certificate will be perfectly ok for logging
>> in
>>  without having to update the credential mapping file/policy.
>>
>>
>> Ultimately, I would discourage allowing automatic UID/Cert field mapping by
>> using some
>> fields within the certificates (especially when not isolating the different CAs
>> - I have
>> not seen anybody pointing out this distinction) because this could easily lead
>> to
>> conflicts in names. Keys or Full DNs, I think, is the way to go.
>>
>> Later,
>> Max
>>
>>
>> Jan Pechanec wrote:
>>> 	hi,
>>>
>>> 	I'm wondering what would be your opinion on suggestion to include
>>> kmf_map_cert_to_username()-like function in KMF API. Mapping a certificate to
>>> a username will be a very common and very needed task which, in my opinion,
>>> should be enforced by a KMF policy.
>>>
>>> 	an example - in x509 support for SSH, we need to somehow get a username
>>> from the certificate. Doing that in SSH, and what's more doing it
>>> configurable, would most probably be a duplication of work that other
>>> applications would need to do, too.
>>>
>>> 	I have materials for pam_pkcs11 ARC case and I have to read it to see
>>> how mappers work there but it would be great, even if I could use it in
>>> SunSSH, if this was offered as part of KMF API.
>>>
>>> 	any thoughts on that?
>>>
>>> 	thanks, Jan.
>>>
>>
>>
> 


-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            pala at cs.dartmouth.edu
                                                  project.manager at openca.org

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3088 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.opensolaris.org/pipermail/kmf-discuss/attachments/20071220/98dc7507/attachment-0001.bin