Re: Recommended change to Unique Identifier handling

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Anne,

Ignoring for a moment Peter's question as to whether any Internet-domain
CAs actually populate UID, I am still curious how an interoperability
problem could arise.

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?

Comments interspersed below ...


> From: Anne Anderson <aha@east.sun.com>
> 
> 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.

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.

> 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.

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?

Dave Kemp