Recommended change to Unique Identifier handling

[Anne Anderson <aha@xxxxxxxxxxxx>]

There are problems with the processing of Unique Identifier values
as currently specified in draft-ietf-pkix-new-part1-00.txt,
including the following:

a) PKIX recommends that PKIX-compliant CAs should not set Subject
   and Issuer UID values.  This makes it impossible for certificates
   from non-compliant CAs that use UIDs to be used as links in a
   chain that includes certificates from compliant CAs.  This
   creates a serious interoperability problem during the period
   before all CAs become fully PKIX-compliant.

b) Assuming a CA is willing to stray from the recommendation in the
   interests of interoperability, then each time the CA signs a CA
   certificate, it MUST know the Issuer Unique Identifier value that
   the subject will store in certificates it generates, and must set
   that value in the certificate's Subject Unique Identifier field.
   Yet the subject may become PKIX-compliant and cease issuing
   certificates with Issuer Unique Identifier values at any time.

c) Again, in the interests of interoperability, each time a CA signs
   a certificate, it MUST know the Subject Unique Identifier stored
   in any certificates that other CAs have signed for itself, and
   MUST use that Subject Unique Identifier as the Issuer Unique
   Identifier in ALL certificates it signs.  Since Subject Unique
   Identifier values are completely arbitrary, they may vary across
   different CAs that create certificates for the same principal.
   This creates an impossible situation.

EXAMPLE
=======

To illustrate these problems, consider the following path example,
and assume that everything except the IssuerUID verifies:

Trust anchor: Issuer:  CA1
              Subject: CA1
              IssuerUID: null
              SubjectUID: null

2nd cert:     Issuer:  CA1
              Subject: CA2
              IssuerUID: null
              SubjectUID: null

3rd cert:     Issuer:  CA2
              Subject: EE1
              IssuerUID: CA2-UID
              SubjectUID: null

According to the current draft-ietf-pkix-new-part1-00.txt, this
certification path should be rejected at the 3rd certificate since
the Issuer Unique Identifier in the 3rd certificate does not match
the "working_issuer_UID", which is null.

RECOMMENDED CHANGES
===================

To address these problems, I recommend that Unique Identifier
matching be used as part of path processing only if the preceding
certificate has a non-null Subject Unique Identifier and the current
certificate has a non-null Issuer Unique Identifier.

In other words, absence of a Subject Unique Identifier field in a
certificate logically means the issuer does not care what Issuer
Unique Identifier value (if any) is used in subsequent certificates.

And, absence of an Issuer Unique Identifier value in a certificate
logically means the issuer does not care (or know) what Subject
Unique Identifier was used in certificates that might preceed this
one in a certification path.

Recommended changes to the text of draft-ietf-pkix-new-part1-00.txt:

[Change 6.1.3 (5) to:]
   6.1.3 Basic Certificate Processing
   ....
         (5) If the certificate issuer unique identifier field is
             present and non-null, and if the working_issuer_UID is
             non-null, then the value of the certificate issuer unique
             identifier must match the value of the working_issuer_UID.

[Add 6.1.5 (h):]
   6.1.5 Wrap-up procedure

   To complete the processing of the end entity certificate, perform the
   following steps for certificate n:
   ....
      (h) If the certificate subject unique identifier field is
          present and non-null, set the value of working_issuer_UID
          to the value of the certificate subject unique identifier
          field.  Otherwise, set the value of working_issuer_UID to
          null.

Anne
-- 
Anne H. Anderson             Email: aha@acm.org
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692