[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X.509 certificate and its subject name field
You can always achieve the effect of a unique identifier by adding an
attribute value assertion into the distinguished name for that purpose.
For example, if Common Name is not assigned so as to be inherently unique,
you can add another attribute that carries Employee Number or Customer
Number, which is arranged to be unique.
This is generally considered much better than using the subjectUniqueId
field since (a) the latter is not transmitted in many protocols; (b) most
products do not implement it and are likely to ignore it; and (c) there is
generally no provision to display it in UIs.
At 12:55 PM 5/23/97 -0700, Shyh-Wei Luan wrote:
>I have some concerns with how people are using X.509 certificates and a
>recommendation of dependending on non-reusable names.
>X.509 certificate has the following two fields that are used to
>define a subject's identity, where the "subject" is the entity being
>The "subject" field identifies the entity with a general name, where
>the subjectUniqueID field is used to handle the possibility of reuse of
>subject's general name. It is currently suggested in
>draft-ietf-pkix-ipki-part1-04.txt, "Internet Public Key Infrastructure, Part
>I: X.509 Certificate and CRL Profile," that the subject name should not be
>reused, and the subjectUniqueID should be left unused.
>Here are two paragraphs excerpted from the draft:
>"The subject name identifies the entity associated with the public key
>stored in the subject public key field. The subject identity may be carried
>in the subject field and/or the subjectAltName extension. If identity
>information is present only in the subjectAltName extension (e.g., a key
>only to an email address or URI), then the subject name may be an empty
>sequence and the subjectAltName extension must be critical."
>"The subject and issuer unique identifier are present in the certificate
>to handle the possibility of reuse of subject and/or issuer names over time.
>This profile recommends that names not be reused and that Internet
>not make use of unique identifiers. CAs conforming to this prefile should
>generate certificated with unique identifiers. Applications conforming to
>this profile should be capable of parsing unique identifiers and making
>I believe that following the above recommendation (of not using unique
>identifiers) will cause significant problems in the future when the PKI takes
>a life of its own. I think that many CA's (Certification Authorities)
>will have long lifetimes. For example, enterprises, government offices,
>international organizations, and even internet service providers will likely
>to become CA's and they will certify a lot of entities. At some point in
>we will see most meaningful and easy to understand/remember names used up.
>(We have already seen this phenomena in popular places on the Internet where
>everyone likes to subscribe to, such as on-line newspaper web sites.) CA
>operators will bear the responsibility to enforce that names are not reused.
>The consequences of breaking the non-reuse policy may be unacceptable.
>Applications (commerce or anything else) will use the subject identity
>to make authorization decisions. If the PKI becomes as successful as today's
>web, there will be millions of Access Control Lists soon. These names
>the basis of the protection against unauthorized accesses of all kinds. Many
>of these ACL's will be longliving, and it will be hard to change them all in
>response to the reuse of a subject name.
>Since names cannot be reused, new names will become more and more
>hard to comprehend and memorize, and different people will have different
>ways in addressing the uniqueness.
>I believe it is natural and should be encouraged, if not required, to always
>associate the subject name with a unique identifier. All the internet
>businesses should be required to use both the subject name and the unique
>identifier as the basis of all authorization decisions. Without this
>requirement, privacy and protection of subject's internet resources,
>assets, etc, can be all at risk. It could become more serious than
>the "Year 2000" problem.
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
firstname.lastname@example.org; Tel: (617)492 2816 x225; Fax: (617)661 0716