Subject: Re: Recommended change to Unique Identifier handling

From: "David P. Kemp" <[email-masked]>
Date: Mon, 14 Feb 2000 15:44:34 -0500 (EST)

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 <[email-masked]>
> 
> 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

---

From: Anne Anderson <[email-masked]>
Date: Mon, 14 Feb 2000 16:22:54 -0500 (EST)

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.

 > with IssuerUID=CA2-UID.  What is the motivation for CA2 to create such

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

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

 > still expect paths to CA2's preexisting EEs to validate.

Point taken.

 > 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: [email-masked]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692