Re: Recommended change to Unique Identifier handling

[Anne Anderson <aha@xxxxxxxxxxxx>]

Peter Gutman writes:
 > Given that no major[0] CA has ever used UID's, is this really an issue?  I 
 > assume (based on the above message) that someone somewhere is currently using 
 > them despite their having been deprecated for some time, but is it the job of 
 > PKIX to accomodate out-of-spec implementations?

In that case, why not just say: if certificate contains a SubjectUID
or IssuerUID, reject the certificate.  I'm assuming there was some
reason for addressing handling of UIDs in PKIX Part 1, and I am
trying to make such handling consistent and interoperable between
compliant and non-compliant CAs.

David P. Kemp writes:
 > In your example, CA2 has a SubjectUID=null, but it issues a cert to EE1
 > with IssuerUID=CA2-UID.  What is the motivation for CA2 to create such
 > an unorthodox cert?

CA2 may not even know that CA1 has issued a certificate for it (it
may be a cross-certificate).  CA2 may have a self-cert that does
have a SubjectUID in it, and it used that as a base when issuing the
certificate for EE1:

  Trust Anchor 2: Issuer:  CA2
                  Subject: CA2
                  IssuerUID:  CA2-UID
                  SubjectUID: CA2-UID


 > Comments interspersed below ...
 > > 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.
 > 
 > In your example of CA1=anchor, CA2, and EE1:  when CA1 signs a
 > certificate for CA2, CA1 MUST know the Issuer UID that CA2 will store
 > in certificates it generates.  That's one way of looking at it, but
 > it seems to reverse cause and effect.  I would look at the situation
 > as:
 > 
 >  1) CA1 issues a cert to CA2 containing a null or non-null SubjectUID.
 >  2) CA2 uses its own SubjectUID as the IssuerUID in all EE certs it issues.
 > 
 > If CA2 wants to become PKIX-compliant and stop issuing UID certs, it
 > can request two certs from CA1 - one with SubjectUID populated to use
 > before the transition, and one with SubjectUID null to use afterwards.
 > Might as well rollover CA2's keypair at the same time, just to make it
 > obvious which EE certs belong in which path.

This would work, although it requires CA2 to know that CA1 is
issuing certificates for it, and it requires CA1 to keep track of
the extra certificate.

 > > 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.
 > 
 > If CA1, CAx, and CAy all issue certs to CA2 with different SubjectUIDs
 > (or different public keys or different Subject names), you have an
 > impossible situation.  UID is not unique in this respect - the issuers
 > simply can't be completely arbitrary in what they say about CA2 and
 > still expect paths to CA2's preexisting EEs to validate.

Point taken.

 > I don't think any change to PKIX UID processing rules is necessary.
 > Assuming that there are currently any CAs which use UIDs, if the CAs
 > can't manage themselves to transition from UID-full to UID-less
 > operation, how could we possibly expect a much more diverse set of
 > client applications to implement your recommended changes?

Because my recommended changes are simple, logical, require no
additional certificates, and make no assumptions about how much the
subject of a certificate knows about the issuers.

In any case, the section 6.1.4 needs to be augmented to explain how
the value of working_issuer_UID is updated in preparation for the
next certificate (e.g. set it to certificate Subject UID).

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