|
>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 |