[kmf-discuss] DN/subjectAltName mapping to username

[Massimiliano Pala]

Hi all,

* 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)

* 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/20071219/918fa660/attachment.bin