RE: Display name attribute

["BENNETT,JEREMY (HP-PaloAlto,ex1)" <jeremy_bennett@am.exch.hp.com>]

> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@iti.salford.ac.uk]
> Sent: Thursday, April 29, 1999 10:40 AM
> To: dboreham@netscape.com; ietf-ldapext@netscape.com; BENNETT,JEREMY
> (HP-PaloAlto,ex1)
> Subject: RE: Display name attribute
> 
> 
> From:           	"BENNETT,JEREMY \(HP-PaloAlto,ex1\)" 
> <jeremy_bennett@am.exch.hp.com>
> 
> > It is unfortunate that the two both use the phrase 
> 'Distinguished Name.'
> > This implies to people that they must be the same. General 
> purpose of each
> > is even similar, provide a unique name for every one in the 
> namespace.
> > When you look further, though, you see that the needs are different.
> > 
> > The X.509 DN is a collection of attributes that represent 
> the holder's
> > verified identity. Each attribute has a meaning in the name 
> as well as the
> > identity. 
> 
> I believe this is the old way of looking at it. With v3 
> certificates, the 
> DN in the cert can still equate to the directory DN (indeed there are 
> good reasons why this should be the case, as this securely binds 
> the certificate to the repository and stops switching of certs in 
> directory entries without people knowing it). Then the General 
> Names extension can hold other attributes that help you identify the 
> person, if the DN on its own is insufficient. This is why we put the 
> email address in the extension and NOT in the DN, as you have 
> done in your example below.

This is only possible if the CA and directory are related in some way. I
don't think it is safe to assume they are. I'm not sure what you mean by
'securely binds' in this context. The secure binding is done by the CA when
it binds the user's public key to the DN and extensions when it signs them.
The directory has no such trust path on a per entry basis. You either trust
the entire directory or not. Just because my directory entry contains your
certificate should not give me any special abilities. 

In addition the DN in the certificate must represent the identity of the
holder. If this identity is dependant on some legal employement
relationship, country citizenship, or reasonable point of contact then this
information must be present in the DN. I'm not aware of any required
extensions that can store this additional information if it is not in the
DN. The reason I say required is that if this information is truly part of
the identity then ALL applications must honor them.

By 'General Names' I'm assuming you mean extensions using the GeneralNames
syntax such as the SubjectAltName. I agree these are useful for additional
attributes. In fact, one of the most useful attributes is the DirectoryName
version of the SubjectAltName. This allows the CA to put a directory pointer
into the certificate so applications can easily find the correct directory
entry.

Although we would have liked to put the email address in an extension
instead of in the DN this was not feasible since most current clients do not
take advantage of many extensions. Specifically, neither Netscape
Communicator (4.x) or Outlook Express recognize the rfc822name in the
SubjectAltName extension. Outlook98 seems to notice it but only under
certain circumstances. Also, most security products will only make decisions
based on the DN in the certificate. 
> 
> >For example consider my two DNs:
> > 
> > Cert: CN=Jeremy F Bennett + 
> E=jeremy_bennett@hp.com,O=Hewlett-Packard
> > Company,C=US,OU=Employees,O=hp.com 
> 
> This is a rather long and convoluted DN. You could extract the email 
> address and company name, put that in the General Names 
> extension, and then the DN would again equate to the LDAP DN. As 
> I said above, there is a good security reason for doing this.
> 
> >LDAP: emailaddress=jeremy_bennett@hp.com,ou=Employees,o=hp.com
> > 
> 
> > Given my perspective, as above, of not having CN in the 
> directory DN at
> > all. I agree with the proposal for a single-valued 
> attribute representing
> > what should be used to display the entry in short list boxes.
> 
> given that jeremy_bennett is unique throughout hp.com, otherwise 
> the email would not work, and assuming everyone has an email 
> address, then cn=jeremy bennett would be just as unique and could 
> be used in the DN. THis would mean that a display name is not 
> needed.

This could be forced to be a true statement but may not always be.
Potentially, I could have two users:
dn: emailaddress=david_smith@hp.com,ou=employees,o=hp.com
...
cn: David Smith
l: Palo Alto

dn: emailaddress=david_smith2@hp.com,ou=employees,o=hp.com
...
cn: David Smith
l: New York

In this case both have the common name of David Smith but they have
different email addresses. 
I may want to create a displayName combining one or two attributes into a
single string that will help people identify these two. 

displayName: David Smith (david_smith@hp.com)
or
displayName: David Smith (Palo Alto)

Both of these versions would be much more useful than the CN of 'David
Smith' 
> 
> >I don't
> > think we should assume that the displayName value would be 
> duplicated in
> > the set of CNs, though. 
> 
> If display name is unique, then it duplicates the functionality of 
> common name, does it not? The only time I see display name of 
> having value, is when meaningful common names cannot be unique, 
> so cannot be used as DNs. We therefore put meaningless stuff in 
> the DN to make it unique, and use display name to view the entry, 
> but accept that several entries will have the same display name.

I agree that displayName is only useful if common names cannot be unique and
cannot be used as DNs. I don't agree that this implies that we would then
put meaningless stuff in the DN. If CN is not a unique RDN then you pick
some other attribute to use as the RDN in place of common name. This can
either be uid or mail or any other identifying attribute. The problem is
that the common user is not used to seeing uid or mail and identifying a
person with it. This is where displayName can be useful. It can provide a
user friendly identifier to help distinquish entries.

Jeremy Bennett
Security and Directory Service Engineering
Infrastructure Portfolio Team
Business Infrastructure Services (E:BIS)
Hewlett-Packard Company