[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UIDs popping up in new-part1



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 <kent@xxxxxxx> 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