Subject: Re: UIDs popping up in new-part1

From: Ari Kermaier <[email-masked]>
Date: Fri, 02 Mar 2001 13:44:59 -0500

The recommendation that Section 6.1.3 be amended to remove references to 
UIDs makes sense; CAs conforming to the current profile should not be 
required to support this mechanism for certificate chaining, nor should 
UIDs be allowed to needlessly complicate the revised validation algorithm.

However, requiring that UIDs be absent from a certificate would be a 
serious error, as would recommending that conforming CAs reject 
certificates containing UIDs. If the certificate in question contains the 
information required to perform chaining and validation as per the current 
profile, why should the CA not be free to ignore the presence of extraneous 
infomation? I think it would be a Very Bad Idea to break backwards 
compatibility for what is essentially nothing more than an aesthetic 
reason. A CA conforming to the current X.509 v3 profile should NOT reject a 
certificate that has a deprecated field from a X.509 v2 profile -- it 
should just ignore that field. Of course, eveyone "knows" that "nobody" 
uses UIDs, but that's not a good reason to break, even hypothetically, 
certificates that do use them unless there's a truly compelling positive or 
negative functional benefit.

Ari Kermaier
Phaos Technology

>Last fall, we agreed to remove issuer and subject unique identifier
>comparison from the validation algorithm. At least, I think we did. The
>argument was that nobody uses unique identifiers and there's no good
>reason to retain support for them.
>
>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>they remain in step (a) (5) of section 6.1.3, which says:
>
>          (5) The certificate issuer unique identifier is the
>          working_issuer_UID, meaning:
>
>             (i) working_issuer_UID is non-null and matches the value in
>             the issuerUID field, or
>
>             (ii) working_issuer_UID is null and the issuerUID field is
>             not present.
>
>But working_issuer_UID is no longer set anywhere. We should either put
>back the text that initializes and updates this state variable or we
>should change this step so that it doesn't refer to this uninitialized
>varible. I suggest that we remove support for unique identifier chaining
>by changing this step to say:
>
>          (5) The issuerUniqueID and subjectUniqueID fields are not
>          present in the certificate.
>
>This will ensure that compliant implementations will not accidentally
>accept certificates that use these fields, since support for these
>fields is no longer required. I also suggest that we change the sentence
>in section 4.1.2.8 that reads "Applications conforming to this profile
>SHOULD be capable of parsing unique identifiers and making
>comparisons."  to read "Applications conforming to this profile SHOULD
>reject certificates that contain unique identifiers."
>
>-Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 02 Mar 2001 18:15:52 -0700

Steve,

Mea culpa, mea culpa.

I read the message too hastily, and confused subject unique IDs with subject key IDs.  I apologize, and can well understand why my description of a potential use didn't make much sense.

Nonetheless, I agree with Ari Kermaier, that breaking backwards compatibility for purely esthetic reasons is a bad idea, unless we can be absolutely convinced that in fact no one uses them, and never will.

Sorry again of the confusion.

Bob

>>> Stephen Kent <[email-masked]> 03/02/01 10:45AM >>>
Bob,

>I strongly disagree that "nobody uses unique identifiers" or that
>"there's no good reason to retain support of them."  And I even
>more strongly reject the notion that just because it is alleged that no one
>uses them, applications SHOULD reject certificates which disprove
>the allegation!

RFC 2459 has deprecated the use of these fields for some time, so 
this is not a new matter. The current RFC states, in part,:

The subject and issuer unique identifiers 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 for different entities and that Internet certificates not make 
use of unique identifiers.  CAs conforming to this profile SHOULD NOT 
generate certificates with unique identifiers.

  Also, your intentionally obfuscated description of how you might 
want to use them is not consistent with the semantics of the fields, 
as noted above, which were designed to allow disambiguation of certs 
when DNs were reused, NOT to locate certs in the way you allude to. 
As you may recall, the motivation for these fields was a directory 
access control problem caused by bad schema design. We came out 
strongly in the RFC against this hack as a way of fixing the problem.

Steve