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

RE: Identification confusion continues



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:carlisle.adams@entrust.com> 
=====
>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:anders.rundgren@jaybis.com]
>> Sent: 	Monday, February 14, 2000 11:09 AM
>> To: 	Stephen Kent; 'Ed Gerck'; ietf-pkix@imc.org; 'Stefan Santesson';
>> 'Magnus Nystrom'
>> Subject: 	RE: Identification confusion continues
>>
>> 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:egerck@nma.com]
>> Sent:  Monday, February 14, 2000 16:54
>> To:  Stephen Kent
>> Cc:  Anders Rundgren; ietf-pkix@imc.org
>> 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
>>