Re: Extension: WG Last Call: draft-ietf-ldapbis-authmeth-15.txt

"Roger Harrison" <[email protected]> Mon, 26 Sep 2005 14:53:52 -0600
Newsgroups gmane.ietf.ldapbis
Message-ID <[email protected]>
>Section 3.1.4 Discovery of Resultant Security Level 
>This refers to 3.2.3 which does not exist. I can't tell what it was 
>intended to reference. 
> 
> 
>Also there are many references to [Protocol] section 4.13.x.x which 
>probably should now be 4.14.xx. 

I fixed the broken references. Thanks for catching them. 


>Section 3.1.5 Server Identity Check 
>This section talks about how a client must verify a server's name 
>against the identity presented in the server's certificate. This clause 
>  ‑ The * wildcard character is allowed in the server name 
>        provided by the user.  If present, it matches only the left‑most 
>        label from the subjectAltName. 
>makes no sense to me. That implies that I can issue an ldap request to 
>e.g. ldap://*.example.com, which at a glance means to perform a DNS zone 
>transfer against example.com and then issue an LDAP query against every 
>DNS host record that's returned. I don't see how it makes any sense for 
>a user to provide wildcarded server names to a client. In RFC2830 it was 
>clear that wildcard characters could be present in the certificate, and 
>that usage makes sense. Why is the use of wildcards reversed here? This 
>invalidates many already‑deployed RFC2830‑conforming server 
>certificates, if nothing else. 

You are correct. The * wildcard character can be included in DNS names in the certificate rather than in the server name provided by the user. I apologize for reversing it.  This will be fixed in authmeth-16 

> 
>Section 3.3 
>2nd bullet 
>confidentially should be confidentiality 

Got it. 
[snipped out original request from Kurt here] 

>‑‑  
>   ‑‑ Howard Chu 
>   Chief Architect, Symas Corp.  http://www.symas.com 
>   Director, Highland Sun        http://highlandsun.com/hyc 
>   OpenLDAP Core Team            http://www.openldap.org/project/ 
> 

Roger