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

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Jul 2003 23:42:31 +1200

>>Elaborate enough?
>Nope.

Well, what more do you want to know?  Shall I communicate it in the form of an
illuminated manuscript?

Peter.

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 24 Jul 2003 13:40:28 -0700

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 24, 2003 9:15 AM
To: Michael Ströder; [email-masked]
Subject: Re: Microsoft and multi-valued RDNs (was: draft minutes)

Stephen Kent,
DST has been useing a multivalued RDN in EndEntity certificates for a number
of PKIs and since 1999 when we started issuing certificates.  We only do
this for End Entities not servers.  Basically the certificate SubDN looks
like the following.

0.9.2342.19200300.100.1.1 = D01E473E000000F58FE3DDDC00000709,E =
[email-masked], CN = Russel F Weiser,O = TrustID personal
certificate,C = US

We have used this with numerous and integrated with many applications.
So is the issue that microsoft Active Directory will not support multivalued
RDNs  or that there Applications don't ?? I'm just trying to understand the
issue more clearly.

----- Original Message ----- 
From: "Michael Ströder" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 24, 2003 3:47 AM
Subject: Microsoft and multi-valued RDNs (was: draft minutes)

>
> Stephen Kent wrote:
> >
> > LDAP Documents:
>  > [..]
> > Biggest issue on the table for the schema document is that
> > Microsoft says it will not support multi-valued attributes (e.g., a
> > terminal RDN that is a set consisting of a common name and a serial
> > number).
>
> Could someone please elaborate on this?
>
> One of my customers is planning to use exactly this naming scheme with
> multi-valued RDNs in a rather large PKI deployment and so we're scared
about
> interoperability issues.
> Ciao, Michael.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2003 17:20:12 -0400

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

---

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 24 Jul 2003 15:02:38 -0700

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:[email-masked]] 
Sent: Thursday, July 24, 2003 2:20 PM
To: Trevor Freeman
Cc: [email-masked]; Michael Ströder; [email-masked]
Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

Trevor,

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 25 Jul 2003 19:42:00 +1200

"Trevor Freeman" <[email-masked]> writes:

>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. 

Yup, that's what I've found too, which is why I sent my earlier "Don't do
that, then" response to Michael Stroeder.  I haven't exhaustively enumerated
all the different behaviours, which app does what, and which version of which
app does what, but it ranges from ignoring everything but a small fixed set of
DN components (C, O, OU, locality, state, and obviously DN) to accepting most
components but not allowing duplicates (e.g. 2 x OU) to accepting dups but not
multi-valued AVAs.  Then the definition of "accept" varies from reading and
discarding (writing it out again removes the value), reading but ignoring
(writing retains the value), displaying or not displaying, etc etc etc.  This
is why, in writeups I've done like "PKI: Not dead just resting" I recommend
that for maximum usability people treat DNs as random blobs and don't try and
do anything fancy with them.  The further you depart from that, the more pain
you're in for.

>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. 

Exactly.  The range of options runs from the simplest possible DNs (C, O, OU,
etc) treated as blobs through to complex DNs, multi-AVA RDNs, etc etc, and
then relying on each component to work properly, with a corresponding increase
in pain level from 0 to infinity along the same scale.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jul 2003 13:20:13 -0400

At 15:02 -0700 7/24/03, Trevor Freeman wrote:
>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
>
We obviously have different experiences.  For example, the DoD PKI 
decided to avoid a terminal RDN SET and as a result the CN is of the 
form "John Smith 123457678901" which qualifies as ugly in my book. 
An organization typically identifies employees/students/members by 
name and ID number, which maps naturally to a terminal RDN set of CN 
+ Serial #.

I don't understand your comment: "Personally I am mystified as to how 
adding an arbitrary number to a name helps a user." The issue is that 
organizations make user names unique by assigning such numbers, and 
have for decades. Thus if we are to minimize the impact on an 
organization's existing naming practices, we need to be able to 
accommodate names that have these two components.  For users, the 
goal is to make the name presented to them as natural as possible. 
Separating the two components using the appropriate attributes 
provides an application with opportunities to do this, whereas gluing 
the two attributes together into the CN makes that very hard, since 
it may not be easy to determine where the real common name ends and 
the ID number or equivalent string, starts.

So, from my perspective, a terminal RDN SET is precisely a realistic 
solution to the problem at hand, except for the refusal of at least 
one major vendor to follow standards and support this solution.

Steve

---

From: "Adrian McCullagh" <[email-masked]>
Date: Tue, 29 Jul 2003 07:22:32 +1000

--------------------------------------------------------------------
FREEHILLS
This email is confidential.  If you are not the intended  recipient,
you must not disclose  or  use the  information  contained in it. If
you have received this email in error,  please notify us immediately
by return email and delete the document.
Freehills is not responsible for any changes made to a document other
than those made by Freehills or for the effect of the changes on the
document's meaning.

Liability is limited by the Solicitors' Limitation of Liability Scheme,
approved under the Professional Standards Act 1994 (NSW)
--------------------------------------------------------------------

Peter,

That isa really good point you make.  Maybe there could be a competition
formed that will pick some PKIX RFCs and award something to the Vendor
whose product complies the most with the selected RFCsand too what extent.

Concluding remark:

Is it worthwhile really calling it a STANDARD if so few vendors (if any at
all) are compliant.

Dr. Adrian McCullagh
Solicitor
Freehills

Direct 61 7 3258 6603
Telephone 61 7 3258 6666
Facsimile 61 7 3258 6444
http://www.freehills.com

                                                                                                        
                          [email-masked].  To:    [email-masked], [email-masked]      
                          ac.nz (Peter          cc:    [email-masked], [email-masked],         
                          Gutmann)                     [email-masked]                             
                          Sent by:              Subject: RE: Microsoft and multi-valued RDNs (was:      
                          owner-ietf-pkix@mail         draft minutes)                                   
                          .imc.org                                                                      

                          28/07/2003 06:25 PM                                                           

Stephen Kent <[email-masked]> writes:

>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.

PKIX, meet the real world.

Actually I'd like to offer a small soapbox here on the out-of-touch-with-
reality nature of many PKI-related RFCs, and the deleterious side-effects
that
this has when the RFC is applied in practice.  For example there's an EDI
messaging standard that had to do X (and also Y and Z, none of them related
to
verifying sigs after the cert has expired as per the recent thread), so
they
went to the appropriate RFCs, picked the way they wanted to do things, and
wrote it into their standard.  Since security always gets bolted on as an
afterthought, the rest of the standard was in use for a year or two before
anyone got around to looking at the security parts of it.  At that point
they
discovered that nothing in existence implemented what they required (poor
guys, they thought that MUST in the RFC implied that it'd be supported),
and
no vendor was interested in supporting it [0].

This situation is unfortunately all too common, with users (and in this
case
the WG chair) discovering that some feature discussed in an RFC as if it
were
a hard fact exists only in the imagination of the RFC author.  What's more
problematic is the case of RFC A relying on an imaginary feature of RFC B
which in turn relies on an imaginary feature of RFC C.  This is why, in
stuff
I write, I include extensive implementation notes with caveats such as "The
standard says MUST X, but in practice no-one does it that way, so be
prepared
to encounter data which doesn't do X at all".

A few years ago I started making a list of features in PKI RFCs, rated from
1-5 in terms of support in implementations, where 1 means "you can rely on
it
being present" and 5 means "don't bother", the idea being that users could
consult it to see whether the feature they wanted was going to be available
in
the real world.  I abandoned it after a while because (a) I didn't think
I'd
make many friends pointing out how little of what was in the RFCs was
actually
supported in practice and (b) there was a kind of geometric growth of
features
as you went further along the scale (i.e. from 1 to 5).

So to sum up I really wish PKIX would at least make some attempt to
approximate the real world.  SSH for example has just had a poll of
implementors/implementations to check for how to handle a new feature being
added, with the primary goal being existing support for it and
compatibility
with current implementations.  The PKIX approach in contrast seems to be to
construct cloud castles, declare the problem solved, and then wonder why
nothing does what the RFC says.

Peter.

[0] Actually I believe that there exists a single experimental/reference
    implemetation that does it, but I'm not sure who uses it in practice.