Subject: RE: Identification confusion continues

From: Anders Rundgren <[email-masked]>
Date: Mon, 14 Feb 2000 17:09:12 +0100

Thanx Ed!
It would be particularly interesting to know who actually use or intend to use serialNumber as a
name collision eliminator.  I.e. the function of dnQualifier according to ITU...

/anders

----------
From:  Ed Gerck [SMTP:[email-masked]]
Sent:  Monday, February 14, 2000 16:54
To:  Stephen Kent
Cc:  Anders Rundgren; [email-masked]
Subject:  Re: Identification confusion continues

>Stephen Kent wrote:

>> After extensive debate, folks in the ITU and IETF worlds agreed that
>> the syntax of what we needed is best expressed by serialNumbner, not
>> DNqualifier, and that a broadening of the definition of the former
>> attribute was the best path.  Moreover, we had reports from various
>> folks that people in the field had come to the same conclusion and
>> were already using serialNumber in this fashion.  So, we are
>> legitimizing current practice, and meeting a stated need, without
>> introducing a new attribute type.

>I may have missed this information in the draft?  Seems to me that it
>at least shows why the seemingly most obscure path was the path of
>choice, by calling a serialNumber what is not a "serial number".

>BTW, could we know what "people in the field had come to the same
>conclusion and were already using serialNumber in this fashion" and
>also who were the "various folks" that reported on this?  It might be
>useful to get back to both sides and see exactly what is being done
>ahead of the standards.

>Cheers,

>Ed Gerck

---

From: Carlisle Adams <[email-masked]>
Date: Tue, 15 Feb 2000 16:45:04 -0500

Hi,

I try to make it a personal policy not to mention Entrust products in this
type of forum (i.e., the PKIX list), but since you asked explicitly, I'll
make an exception.

The Entrust PKI allows the terminal RDN in a DN to be something like
"cn=Fred Smith + sn=12345".  That is, a serial number (for example, an
employee id.) may be used to ensure uniqueness in DNs that might otherwise
clash (due to non-uniqueness of the common name in a large organization).
Nothing mandated, of course; this is just a possible way of populating the
DN field.

My understanding is that a number of our customers have chosen to configure
their DNs in this way.  This actually is current practice in many real
environments.

I'd be surprised if Entrust was the only product that allowed this but, in
any case, it's one data point.

Carlisle.

> ----------
> From: 	Anders Rundgren[SMTP:[email-masked]]
> Sent: 	Monday, February 14, 2000 11:09 AM
> To: 	Stephen Kent; 'Ed Gerck'; [email-masked]; 'Stefan Santesson';
> 'Magnus Nystrom'
> Subject: 	RE: Identification confusion continues
> 
> Thanx Ed!

---

From: Charles Moore <[email-masked]>
Date: Wed, 16 Feb 2000 15:20:55 +1000

Another data point, we allow dnq in out certifiactes exactly as Entrust do
for 
SN ( I now understand their position in the ITU on this matter)..
Anyway this is in "Root certificates that exist within MSoft and Netscape 
Browers so there are X??Million in existance today...

Just another data point...
We use DNq as it has the right semantics, we also have installations that
use 
serial number but with the right semantic...

Enjoy...

>===== Original Message From Carlisle Adams
<SMTP:[email-masked]> 
=====
>> It would be particularly interesting to know who actually use or intend
to
>> use serialNumber as a

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 16 Feb 2000 06:32:58 -0000

Carlisle,

>type of forum (i.e., the PKIX list), but since you asked explicitly, I'll

thanx!

>their DNs in this way.  This actually is current practice in many real

I would not say that employee ids has much to do with name clashes.  Employee ids
are in 99.9% of all cases unique identities.  Name independent.  These fit the serial number description
without tweaking the original specification more than replacing device with individual.

I.e. I stay unconvinced that serialNumbers are used as dnQualifiers (which I am pretty sure
that Entrust support as well?)  in the way it was interpreted by most of the PKI community
just some months ago.

But actually this does not matter at all.  What DOES matter is that the ambigious
use of serialNumber in QC is not left in its current UNDEFINED state.

Anders