Subject: RE: [ldapext] draft-ietf-ldapext-locate

From: "Paul Leach" <[email-masked]>
Date: Wed, 14 Aug 2002 16:10:18 -0700

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]] 
> Sent: Tuesday, August 13, 2002 21:36
> To: Patrik Fältström
> Cc: Michael Armijo; Paul Leach; Levon Esibov; 
> [email-masked]; [email-masked]; Ned Freed; [email-masked]
> Subject: Re: [ldapext] draft-ietf-ldapext-locate
> 
> 
> At 02:53 AM 2002-08-13, Patrik Fältström wrote:
> >This document define a conversion that is over-restrictive.
> 
> I disagree.   I also note that this issue has been discussed
> repeatedly on the list and, IMO, consensus has been that the 
> current specification is appropriately restrictive.

<snip>
I summarize Kurt's comments for myself as follows: while what Jeff
proposes might make sense in a PKI certificate scenario, perhaps because
the way certs have been issued means that order of components in
SubjectName DNs has been defined to be of no significance, it isn't
desirable in general.

In addition, I at least don't know that I understand the PK scenario
very well.
If I have a certificate for user with DN "X" in my hands, why do I need
to locate an LDAP server for DN X? Certainly not to get the cert for
that user, which seems like the most obvious reason. If I don't have
such a cert, how did I get the user's DN? Isn't it more likely that I
know the user's email address and want to get their cert so as to send
them S/MIME protected email? Also, I know that cert chains contain
NameContstraints that say what names subordinate CAs can put in their
certs -- if I issued a subordinate CA cert for "OU=CompSci, dc=mit,
dc=edu, O=MIT, C=US", expecting that all the certs they issue will be
stored in the LDAP server for "mit.edu", is it really OK that the new CA
issues a cert ending with "dc=cs, OU=CompSci, dc=mit, dc=edu, O=MIT,
C=US" and that the lookups go to the "cs.mit.edu" server? Are there
other security considerations?

Since I didn't know the answers to the above, I at least did not feel
comfortable specifying behavior whose ramifications I didn't understand.
Instead, what we did was make sure that what we wrote did not preclude
anyone else from extending this standard. When this issue came up in the
WG, I said that what I thought should happen is that someone who
understands the PK issues should write an I-D that says how, in certain
PK scenarios, one should use the DN in a SubjectName to locate an LDAP
server for whatever the PK purpose for doing so is. They can certainly
leverage our proposal -- for example, the spec could simply say to
rewrite the DN so that all the DC components are on the right hand side
in the same order, and then apply our proposal, and then describe what
the security considerations are.

I still think that's the right way to handle this issue.

Paul

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Aug 2002 12:36:30 +0200

>>-----Original Message-----

snip

> them S/MIME protected email? Also, I know that cert chains contain

I think cert path construction is a better application to think about.
You have the issuer name and need to find the issuer cert. This is a 
real problem but it arises from the fact that most pki applications
have used the issuer and subject DN fields both as "display" names and 
adresses (into a instead of using subjectAltName to locate certificates.

This is a misstake and the current discussion about what meaning to 
assign to DN's in the context of certificates and ldap is a result
of the fact that DN's in ldap are *only* used as adresses whereas DN's
in certificates are both used as addresses (into something -- the global
DIT -- which doesn't even exist) and as a source of displayable user 
information.

	leifj

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Leif Johansson <[email-masked]>
Date: Thu, 22 Aug 2002 09:23:00 +0200

David Chadwick wrote:
> Leif Johansson wrote:

  snip snip

> 
> Leif is correct in saying that DNs in certs are used for two purposes,
> but I dont see a problem in that, if the DN is a permanent DN that does
> not change with time.
> 
> regards
> 
> David

It is a problem if your ldap dn design is incompatible with the pki
dn design which it often is! For instance the recently much debated
situation where uid=u4711+cn=Joe Random,... is used in the pki dn
whereas uid=u4711,... is used in your directory where multivalued
rdn's suck. But I digress from the main topic of this thread.

	leifj