|
Hi there, It has been
long since the last time I posted something so happy to be back J 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. |