Subject: R: ID cards certificate profiles

From: "Santoni Adriano" <[email-masked]>
Date: Mon, 26 Feb 2007 10:28:01 +0100

Malek,
 
I am just addressing your points #1 and #2, in the following.
 
As far as signing certificates are concerned, I would suggest you not to reinvent the wheel, but adopt an existing profile as much as possible. 
 
Overall profile: as a general rule, I would follow RFC 3739 and ETSI TS 102 280.
 
CommonName: I would avoid putting into the CN something different than the owner's name.
 
Ciitizen civil ID: assuming you mean something like a fiscal code or social security number, you should put this into the serialNumber RDN.
 
NonRepudiation: I would stick to the guidance you find in ETSI TS 102 280, section 5.4.3
 
Regards,
  Adriano

________________________________

Da: [email-masked] [mailto:[email-masked]] Per conto di Bechlaghem, Malek
Inviato: martedì 23 gennaio 2007 11.08
A: [email-masked]
Oggetto: ID cards certificate profiles

Hi there,

It has been long since the last time I posted something so happy to be back :-)

I am working on the implementation of a PKI infrastructure needed for an ID cards issuing project. Part of my job is defining the needed certificate profiles which are raising some open issues that I am listing below and hope to have your support in resolving them.

1.       Are there any particular issues when not adding any surname and given names in the CN of the subject field of end-entity certificates knowing that these EE are the actual ID cardholders. My understanding is that the subject field is used mainly to provide the data that identifies the certificate holder. Moreover, knowing a person's name, so if I am looking for her certificate, I could use the name to perform LDAP lookup based on that name. However, in our case, the certificates are not published in an LDAP and the persons names are often very long. This is why we thought not using first and last names in the CN of the subject field. Instead, we are considering the following format for the CN: 

Common Name (CN) = < Certificate Type = <AUTH/SIGN>, Citizen civil ID>

2.      Assuming that the country issuing ID cards does not have a digital signature law and no clear definition of NON REPUDIATION, should we avoid using the NR bit of the key usage extension for signing certificates (not authentication certificate)? We could set the digitalSignature bit only and explain in the certificate profile the applicability of the certificate including those situations where it would be difficult for the cardholder to repudiate a signature? We could simply set the NR bit. 

3.       We are not planning to use the SubjectKeyIdentifier extension as the card returns a complete certification path with a signed message. Would this be OK or are there reaons to use this extensions.

4.       For the certificatePolicies extension, the plan is to use a CPS qualifier with the CPS OID. Is there any reasons for deviating from this? We could for instance use the OID of the CP under which a certificate is issued. Assuming that the Certification Authority issues other types of certificates apart from the ID cards certificates, and that these certificates may have different assurance levels, what's the right option we should opt for when formatting the certificatePolicies extension?

5.       We are not planning to use the basicConstraints extension for EE certificates. We will use it for CA certificates setting the pathLengthConstraint to zero. This prevents cross certification at the subordinate CAs level which is a functional requirement since we are expecting cross certification with other CAs to occur at the root CA level. Could you please confirm that our settings for the basicConstraint extension are correct.

6.       Assuming that the LDAP directory on which CRLs will not be public,  

Thank you all for your prompt feedback.

M. Bechlaghem

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.