|
In-line From:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf
Of Dave Engberg 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: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Bechlaghem, Malek 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. |