For item 1, clearly a non-issue. For 2, it might still be helpful to
have search base information in an SRV record, especially if it is in the same PKI repository locator service record. It will eliminate that extra call to the directory to get the naming context info and might also help in cases where a third party service provider is operating the directory and has a large number of naming contexts, only one of which is of interest for a specific domain's PKI data. I agree that the basics are already there, but as PKI deployments grow to very large scale, some efficiency could be be achieved by reducing the number of calls required to a directory and the amount of data returned from each call.
Sharon
> -----Original Message-----
> From: Michael Ströder [mailto:michael@xxxxxxxxxxxx]
> Sent: Thursday, January 11, 2001 9:15 AM
> To: ietf-pkix@xxxxxxx
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
> Sharon Boeyen wrote:
> >
> > Finding a particular certificate is
> > one problem and determining whether or not to 'trust' and make use
> > of it is another.
>
> Agreed.
>
> > I do agree that 2377 and the PKIX repository locator document are
> > a nice fit and will satisfy a lot of the requirement for many
> > environments.
> > [..]
> > we don't yet have an answer is the provision of search base
> > data for LDAP SRV records for PKI repositories.
>
> ??? You simply don't have to provide the LDAP search base in DNS.
>
> 1. If you are using RFC2377 naming and RFC2782 SRV records you're
> looking up the server's DNS entry/IP address by already knowing the
> dc-style search base. If you want to locate the entry of a given
> e-mail address I would suggest that one searches all the sub-domains
> up to top-level domain if you can find a SRV record. After that you
> do a search for the e-mail address with this matching search base.
>
> 2. If you contact a given LDAPv3 server you can retrieve his search
> base(s) by looking at the namingContexts attribute in the RootDSE.
> (A similar non-standard work-around exists for UMich-derived LDAPv2
> servers.)
>
> Example for 1.:
>
> a) Assuming you want to locate an entry for
> webmaster@xxxxxxxxxxxxxxxx for retrieving the certificate and your
> client implementation is capable of searching the SRV RR in the DNS.
>
> 1. You search for SRV record _ldap._tcp.www.stroeder.com. -> no
> result
>
> 2. You search for SRV record _ldap._tcp.stroeder.com. -> RR points
> to LDAP server directory.adm.stroeder.com.
>
> 3. You're doing the LDAP search
> ldap://directory.adm.stroeder.com/dc=stroeder,dc=com??sub?(mai
l=webmaster@xxxxxxxxxxxxxxxx)
>
> b) If your client implementation is not capable of searching the SRV
> RRs itself but is able to follow LDAPv3 referrals (search
> continuations) it uses a service like described on
> http://www.openldap.org/faq/data/cache/393.html and gets redirected
> to the right server when doing a search like
> ldap://root.openldap.org/dc=www,dc=stroeder,dc=com??sub?(mail=
webmaster@xxxxxxxxxxxxxxxx).
>
> Now what's the problem? This can all be done without writing a new
> draft or modifying an existing one. Just a matter of implementing
> it...
>
> Ciao, Michael.
>