Subject: ID cards certificate profiles

From: "Bechlaghem, Malek" <[email-masked]>
Date: Tue, 23 Jan 2007 14:08:11 +0400

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.

---

From: "Dave Engberg" <[email-masked]>
Date: Tue, 23 Jan 2007 12:09:29 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Bechlaghem, Malek
Sent: Tuesday, January 23, 2007 5:08 AM
To: [email-masked]
Subject: 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: 

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,

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.

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 23 Jan 2007 12:12:31 -0800

In-line

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Tuesday, January 23, 2007 9:09 AM
To: Bechlaghem, Malek; [email-masked]
Subject: RE: ID cards certificate profiles

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.

[rmh] Yes, Windows often uses a API called GetCertNameString
(http://msdn2.microsoft.com/fr-fr/library/ms937665.aspx ) and a option
it exposes called SimpleName which prefers the CN over other parts of
the DN, it doesn't even look at the given name and surname. 

[rmh] Also can't stress the confidentiality issues enough with
certificate profiles, you certainly need personally identifiable
information in the certificate but protocols often exchange certificates
as part of a bootstrap for a session and they will be visible in the
clear if used in these protocols (the receiving end of a TLS session for
example).

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.

 [rmh] I agree, Windows generates them automatically to facilitate key
based chaining (preference) if they are not there.

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.

[rmh] Also be aware of how the use of CP will effect your
interoperability with existing clients (browsers, etc) that do not
properly support CP, Windows is fine XP and up but pre-xp that isn't
necessarily the case. I am also I am surprised how many poorly
constructed certs are out there with CPs, many don't nest and meet the
CP processing rules; you don't want to be one of these.

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.

 [rmh] Yes, you want to do HTTP based distribution of CRLs, and you
definitely also want OCSP support (pre-produced responses, etc)

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bechlaghem, Malek
Sent: Tuesday, January 23, 2007 5:08 AM
To: [email-masked]
Subject: ID cards certificate profiles

Hi there,

back J

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.