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

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Jul 2003 22:43:19 +1200

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:
>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?

Using multi-valued RDNs is very risky because it breaks a lot of software (not
just Microsoft's stuff).

Elaborate enough?

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 24 Jul 2003 13:02:13 +0200

Peter Gutmann wrote:
> Michael_Ströder <[email-masked]> writes:
> 
>>Stephen Kent wrote:
>>
>>>LDAP Documents:
>>>[..]

I already know that.

> Elaborate enough?

Nope.

Ciao, Michael.

---

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

>Using multi-valued RDNs is very risky because it breaks a lot of software (not

Last year we tested IE and Netscape clients and they processed 
multi-valued, terminal RDNs with no problems.  It also was not a 
problem for Apache web servers.  I did not test IIS or other servers 
at the time. Anyway, apparently the concern is not a client side 
issue for these very (most?) widely deployed products. I think David 
indicated that he had been told it was a server issue of some sort 
for MS.

Steve

---

From: Leif Johansson <[email-masked]>
Date: Sun, 27 Jul 2003 10:31:20 +0200

The fundamental problem (imo) is that pki confuses the address with the 
name in
the current use of subject and issuer DN. Using multivalued "terminal" 
rdns for
EE is as we all know the result of wanting to have a readable component 
(the name)
along with a unique component (the "address"). The corresponding problem 
has been
cropping up all over the ietf of late (for instance in the recent 
discussion on ipv6
multihoming).

Speaking from the LDAP community my view is that the use of multivalued 
rdn's
is as dead as the Dodo. Get over it.

       Cheers Leif

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jul 2003 10:47:16 -0400

At 10:31 +0200 7/27/03, Leif Johansson wrote:
>The fundamental problem (imo) is that pki confuses the address with 
>the name in
>the current use of subject and issuer DN. Using multivalued 
>"terminal" rdns for
>EE is as we all know the result of wanting to have a readable 
>component (the name)
>along with a unique component (the "address"). The corresponding 
>problem has been
>Speaking from the LDAP community my view is that the use of multivalued rdn's

I disagree with your analysis, in almost every detail.  The names are 
names, not addresses.  I can imagine that from an LDAP perspective 
you think if these names as inputs to locating database entries, but 
this is a rather narrow view for several reasons.Certs exist separate 
from directories, despite the origin of certs as an X.500 construct. 
Moreover, there are many ways to locate  directory entries, and the 
DN is but one. Yes, people get confused by names vs. addresses,  and 
the topic has been hotly debated for over 25 years.  I refer you to 
John Shoc's paper form the later 70s' on this topic.

Speaking from the PKI perspective, LDAP is not the center of the 
universe. Get over it. :-)

Steve

---

From: Leif Johansson <[email-masked]>
Date: Mon, 28 Jul 2003 16:57:57 +0200

Stephen Kent wrote:

> names, not addresses.  I can imagine that from an LDAP perspective you 
> think if these names as inputs to locating database entries, but this 
> is a rather narrow view for several reasons.Certs exist separate from 
> directories, despite the origin of certs as an X.500 construct. 
> Moreover, there are many ways to locate  directory entries, and the DN 
> is but one. Yes, people get confused by names vs. addresses,  and the 
> topic has been hotly debated for over 25 years.  I refer you to John 
> Shoc's paper form the later 70s' on this topic.

That is precisely my point but I could have made it clearer. If your 
only requirement is uniqueness
then serial is enought. Trouble ensues when you try to use the 
identifier for something else (readability).

> universe. Get over it. :-)

In terms of actual deployments I'd say LDAP is "slightly" more 
wide-spread of the two. If
a feature which is in the standard (multivalued rdn's) is not 
implemented by leading vendors
it is for all intents and purpouses dead. Relying on it from the pkix 
community is clearly not
a good idea if you are looking for interoperability with *existing* 
deployed directories.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jul 2003 11:12:44 -0400

At 16:57 +0200 7/28/03, Leif Johansson wrote:
>Stephen Kent wrote:
>
>>
>>I disagree with your analysis, in almost every detail.  The names 
>>are names, not addresses.  I can imagine that from an LDAP 
>>perspective you think if these names as inputs to locating database 
>>entries, but this is a rather narrow view for several reasons.Certs 
>>exist separate from directories, despite the origin of certs as an 
>>X.500 construct. Moreover, there are many ways to locate  directory 
>>entries, and the DN is but one. Yes, people get confused by names 
>>vs. addresses,  and the topic has been hotly debated for over 25 
>>years.  I refer you to John Shoc's paper form the later 70s' on 
>>this topic.
>

people manage ACLs that use cert DNs as inputs for authorization. 
people examine DNs to make value judgements about names, e.g., in 
received S/MINE e-mail.  Thus it is important for DNs to be 
meaningful to people when they perform these functions.

>it is for all intents and purpouses dead. Relying on it from the 
>pkix community is clearly not

PKI gave up on ubiquitous directory availability long ago. Many apps 
that use PKI never need use a directory to locate a cert, because 
certs can be passed in the protocols (e.g., IKE & SSL/TLS). The same 
is true for CRLs in IKE. There are apps that benefit greatly from 
directory storage of certs, but if the LDAP won't support 
multi-valued RDNs we'll just have to use other directory models. The 
AIA and SIA extensions to permit this.

Steve

---

From: Leif Johansson <[email-masked]>
Date: Mon, 28 Jul 2003 17:29:16 +0200

Stephen Kent wrote:

> received S/MINE e-mail.  Thus it is important for DNs to be meaningful 
> to people when they perform these functions.

I know - that is one of the bad side-effects of the current pki naming 
scheme.

> directory storage of certs, but if the LDAP won't support multi-valued 
> RDNs we'll just have to use other directory models. The AIA and SIA 
> extensions to permit this.

And how many of these directores are deployed today? Are you building a 
research project
or are you building something which will actually be used by people 
outside of the pkix-wg??
The bottom line is that directores are widely deployed and pki is not. 
If pki is to have any
chance to get integrated with the provisioning systems which *are* 
*already* deployed and
used in enterprises today it must work with LDAP. No extensions. No 
add-ons.

> Steve

    MVH leifj

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jul 2003 11:56:53 -0400

At 17:29 +0200 7/28/03, Leif Johansson wrote:
>I know - that is one of the bad side-effects of the current pki naming scheme.

This is not a side effect, it is an essential element of any ID-based 
authorization scheme.

>>PKI gave up on ubiquitous directory availability long ago. Many 
>>apps that use PKI never need use a directory to locate a cert, 
>>because certs can be passed in the protocols (e.g., IKE & SSL/TLS). 
>>The same is true for CRLs in IKE. There are apps that benefit 
>>greatly from directory storage of certs, but if the LDAP won't 
>>support multi-valued RDNs we'll just have to use other directory 
>>models. The AIA and SIA extensions to permit this.
>
>And how many of these directores are deployed today? Are you 
>building a research project
>The bottom line is that directores are widely deployed and pki is 
>not. If pki is to have any
>used in enterprises today it must work with LDAP. No extensions. No add-ons.

I won't continue arguing with you about the primacy of LDAP. Either 
it will support PKI needs, or something else will be used to the 
extent that PKI apps require directories. So far, LDAP has not done a 
great job of supporting PKI requirements, as evidenced by the long 
running ;binary debate. Your comments are illustrative of a 
directory-centric mindset that perpetuates these sorts of problems.

Steve

---

From: Leif Johansson <[email-masked]>
Date: Mon, 28 Jul 2003 18:02:51 +0200

Stephen Kent wrote:

>
> I won't continue arguing with you about the primacy of LDAP. Either it 
> will support PKI needs, or something
>
I agree - let's not beat this particular horse anymore :-)