|
1. Most common PKI-enabled applications will display
the value of the subject Distinguished Name without doing any LDAP
lookups. For example, a signed document will display the signer's
name using the CN from the cert, not an LDAP lookup. While you may
set the CN to an opaque encoded string like you describe, this may make the
certs confusing to use, since the signer will be listed as "Certificate
Type=SIGN, 12345678", rather than "Malek Bechlaghem".
If your policies prevent you from putting the cardholder's
name in the cert (e.g. for privacy), then you may want
to consider using the "serialNumber" attribute in the DN
instead of the CN attribute.
2. The meaning of the NR bit is unclear in the
absence of a specific law. This has been the topic of a lot of discussion,
and I don't think you're going to get a great answer on this
question.
3. RFC 3280 requires the subjectKeyIdentifier for
all CA certs ("MUST") and recommends for EE certs ("SHOULD"). In practice,
sKI and aKI have limited value for implementors since the method of deriving
them from the key isn't mandatory, so a relying party has to process
non-matching sKI + aKI pairs already.
4. If you are including Certificate Policies, you
may want to consider including more than one policy OID if the certificate may
be used for different purposes (e.g. different assurance levels). For
example, you could put in an OID for "low assurance" and another for "high
assurance". Later, you could then issue different cards (e.g. non-citizen
visitors) that only include the "low assurance" OID. This would allow each
application to choose its level of assurance by selecting the initial policy set
to the validation algorithm.
5. basicConstraints may be omitted from EE certs. The pathLen
may be zero on the certs issued to your subordinate CAs. You can't rely on
the behavior of a "pathLen" value in the self-signed (root) cert, so you may
want to omit it to avoid confusion.
6. For a PKI to scale to support a national ID, you don't want to
distribute revocation information via LDAP+CRL. The CRLs could easily grow
to hundreds of megabytes per day. Most large ID projects (e.g. US
government ID cards) are migrating to OCSP for revocation
checking.
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Bechlaghem, Malek Sent: Tuesday, January 23, 2007 5:08 AM To: ietf-pkix@xxxxxxxx Subject: ID cards certificate profiles 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. |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature