> -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Tuesday, August 13, 2002 21:36 > To: Patrik Fältström > Cc: Michael Armijo; Paul Leach; Levon Esibov; > rlmorgan@washington.edu; ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature