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