RE: Identification confusion continues

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

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
>