[kmf-discuss] DN/subjectAltName mapping to username

[Jan Pechanec]

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.
>>
>
>
>

-- 
Jan Pechanec