Subject: Re: QC: VERISIGN uses UIDs!

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 10 Nov 1999 08:12:31 -0000

Steve, why have you put me in your "mail-auto-rejection" filter?

>If we followed VeriSign's behavior re certificate syntax, we would 
>also encourage e-mail names hacked into DNs, CPS text embedded in 
>certificates, etc.  I'm afraid I don't consider VeriSign to be the 
>reference standard for certificate syntax.
>
>Steve

1. VeriSign was indeed involved in making RFC2459

2.  Im am NOT arguing about syntax.  I am arguing about the PRINCIPAL use of UIDs in
certificates.  Also I am trying to make you and Stefan realize that UID support is a
MARKET REQUIREMENT.  And exactly how you achieve it (what you call it and where
you put it)  is another issue that I believe that you are fully capable to perform.

But FIRST we must agree (seems unlikey though) on the SEMANTICS particularly with respect to
certificate comparisions and the state of the other attributes when an "UID-enabled"
certificate is found.

3. Is the product manager for GTE CyberTrust willing to atttest here and now
that GTE (unlike VeriSign) will never engage in creating commercial certificates
using UIDs (of some kind)?

Anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Nov 1999 10:50:05 -0500

>Anders,

You are certainly not on an auto-discard filter of mine.  I read ALL 
the PKIX traffic since I consider it my responsibility as co-chair. 
I don't respond to all of it, not even all of your messages :-), but 
I do read it.

>1. VeriSign was indeed involved in making RFC2459

yes, so?

>you put it)  is another issue that I believe that you are fully 

I agree that we should focus on the principle of UIDs first, the 
discuss the syntax later.  I presume you are aware of why the Issuer 
and Subject UIDs were added in v2 certs, and why they are almost 
never used, and why their use is deprecated in 2459. If not, then we 
have a communication problem, since one should be aware of the 
history of these matters before advocating analogous capabilities.

>certificate comparisions and the state of the other attributes when 

You noted above that you are trying to convince the WG of the market 
need for UIDs.  Unfottunately, that's hard for an individual to do. 
We all deal with some set of clients and these clients want solutions 
to their problems in the simplest possible fashion.  However, we're 
in the business of creating standards and inserting fields in data 
structures to satisfy individual customer needs is not a good 
approach to devising standards.  We already have several examples of 
how such behavior has been detrimental to interoperability. Thus we 
need to proceed with caution.

>using UIDs (of some kind)?

I don't know what the CA product manager might say, and I would not 
let his position influence my decision, unless he could make a 
compelling, general case.  In order to sell a product, vendors will 
often make decisions that are poor decisions from a standards 
perspective.  I have witnessed them internally and externally and 
been equally critical in both contexts. I spend a moderate amount of 
time acting as an advocate for standards in CyberTrust; I don't 
recall ever acting as an advocate for CyberTrust product features in 
PKIX.

Steve