Re: comments on draft-ietf-ldapext-ldapv3-tls-01.txt

[RL Bob Morgan <Bob.Morgan@Stanford.EDU>]

On Thu, 23 Jul 1998 Jeff.Hodges@stanford.edu wrote:

> ...
> > In the absence of a subjectAltName extension of type dNSName in the
> > certificate: how should  the compare algorithm should look like, as
> > the only ldap server name in the cert - the  subjectName field - will
> > be an X.500 Distinguished Name? Some RDNs may contain rfc822MailBox
> > names or something else that allows a mapping onto the servers
> > hostname.  
> 
> > The cert may also contain subjectAltName extensions distinct from
> > dNSName, but nevertheless  suitable for identity check, e.g
> > rfc822Name, uniformResourceIdentifier or iPAddress.  
> 
> Defining this check down to every last possibility is something we've been 
> hoping to avoid. The check is based on the one in draft-ietf-tls-https-01.txt 
> and is written as per conversations with Jeff Schiller and Harald Alvestrand. 
> ...
> I'm inclined to leave our text as-is for now, but raise this issue on 
> ietf-pkix@imc.org (e.g. "hey, we think that end-entity server certs should 
> have a subjectAltName of type dNSName whether or not they have a subjectName, 
> because of this client checking the server thing, what do you folks think?") 
> and see what they have to say.

We had a discussion on just this question (whether and how a TLS client
should check the server-supplied cert with the server's name and/or
address) at the ldapext WG session in LA.  One knowledgeable opinionated
person said that if this check isn't fully specified and absolutely
required we may as well throw all the other security out the window. 
Another knowledgeable opinionated person said this issue is such a mess
and so poorly understood that we would be jumping into a deep black hole
if we even mentioned it in the spec.  We concluded that consensus is
lacking, hence the weasel wording in the spec.  I strongly suggest that we
don't want this issue to hold up this document. 

 - RL "Bob"