Subject: Re: UIDs popping up in new-part1

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 01 Mar 2001 10:21:19 -0700

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!

I don't want to go into too much detail regarding a usage that would
be proprietary in any case, but we are considering the use of unique
IDs in order to facilitate finding and retrieving the appropriate keys in 
a network-wide context, where the consuming application, the 
encrypted data (if applicable), and the server on which the key
is stored (in encrypted form) may all be separate, and may tend to 
migrate apart in a more or less unconstrained fashion.  We observe that
servers are often split due to increased workload, or perhaps merged 
as servers are replaced with more powerful models, directory information,
including encrypted information is often replicated to other servers, but 
not all servers may have access to the encryption keys (perhaps they 
are stored on a smart card which is unique to only one server), and 
 less-often accessed data is frequently migrated to archival media.

These can often be extremely complex issues, sometimes involving
terabytes of information.  The data may be essential to the operation, 
or it may be important business records that must be preserved for legal
reasons, but are not all that often accessed.  Perhaps the data itself
is migrated to an off-site backup facility, but the key is retained in a smart
card.

In any case, the use of unique ID that may include some useful information
as to where the was generated or resides can be extremely helpful, and
yet can be dealt with using a standardized mechanisms that is quite compact.

Regards,

Bob

>
>>>> Steve Hanna <[email-masked]> 02/28/01 03:25PM >>>
>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

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Mar 2001 12:45:34 -0500

Bob,

>uses them, applications SHOULD reject certificates which disprove

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 30 Mar 2001 17:24:06 +0200

The answer to the question on how individuals should securely authenticate to business parties
have so far been: Use client-certificates and SSL-authentication.  Drawbacks:

- There is no global issuing of  "employment certificates"

- To become a CA or RA under somebody else's umbrella is not core business and does neither
  scale-up (large organizations want to do this themselves), nor scale-down (too complex and expensive)

- If every organization instead becomes a stand-alone CA the whole concept of trust disappears
  and business parties will have to constantly install new root certificates

- X509 certificates do not contain the information needed for many relations which leads
  to out-of-band maintenance of  user attributes which make certificates pretty useless

- IETF attribute certificates have currently almost no infrastructure support

- Bridge CAs address problems that are entirely imposed by poor use of PKI

On  http://buyer.x-obi.com  you can get a glimpse of the future of PKI for B2B.  
Enjoy a free PKI-secured B2B-ride!

Tech/marketing whitepaper:  http://www.x-obi.com/purple

A future standard based on the same basic concept is created in the OASIS security-service TC.

regards
Anders Rundgren
CEO X-OBI AB
+46 70 - 627 74 37