RE: Microsoft and multi-valued RDNs (was: draft minutes)

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxx>]

Hi Steve,
First off, I am simply providing feedback as to what people do in real deployments. So far the deployments I have seen are effective at meeting the needs of the organisations without braking existing applications. Personally I am mystified as to how adding an arbitrary number to a name helps a user. Every time I have seen an example of such a multi-valued RDN, they look pretty ugly to me. To be widely adopted, a standard has to be a realistic solution to the problem at hand.

Trevor

-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx] 
Sent: Thursday, July 24, 2003 2:20 PM
To: Trevor Freeman
Cc: RWEISER@xxxxxxxxxxxx; Michael Ströder; ietf-pkix@xxxxxxx
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

At 13:40 -0700 7/24/03, Trevor Freeman wrote:
>Yes there is a difference between a DN with multiple RDNs which is 
>what you depict and an individual RDN having multiple values. Most 
>commonly used applications like SSL and SMIME don't use the DN but 
>used other name types such as DNS or email so the presence of 
>multi-valued RDNs is benign.
>
>IE is a case in point where it only processes a single value (the 
>common name) from the DN and only then if there is no DNS name in 
>the subject alt name. Therefore I can readily believe in that case, 
>no problem was found when testing with multi-valued RDN's.
>
>The scope for applications not doing the right thing in the presence 
>of a multi-valued RDN is pretty big. Fore example, there is a large 
>body of applications who extract subsets of data from the DN such as 
>only using the common name in UI which will ignore subsequent values 
>of the RDN. Therefore Microsoft's lack of support for multi-valued 
>RDN with AD is the tip of the iceberg and anyone insisting on using 
>them will have a lot of regression testing to perform. This is why 
>typically the more pragmatic solution is to simply append some data 
>to the sting used for the common name to make the CN unique.
>
>Trevor
>

Trevor,

I appreciate the clarification, but I am appalled by the suggestion 
that people should construct ungainly CNs that will be hard for users 
to parse, or that LDAP schema should be skewed to accommodate this 
lack of standards compliance.

Steve