|
Hallvard,
You've persuaded me to rethink my approach to the server identity check section. I've made some adjustments to remove the ordering. Here's my proposed replacement for rules 1-3 in the -16 draft:
The client determines the type (e.g. DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity is verified and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1-3.1.3.3 explain how to compare various types of subjectAltName.
The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped, however the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g. extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner that is not subject to attack (e.g. using DNSSec, or using user- (or admin-) configured host-to-address/address-to-host lookup tables).
The server's identity may also be verified by comparing the reference identity to the Common Name value of the least significant RDN of the subjectName field of the server's certificate. Note that the TLS implementation may display DNs in certificates according to X.509's rules rather than LDAP's rules. For example, RDNs in a DN may be ordered left‑to‑right instead of right‑to‑left. This comparison is performed using the rules for comparison of DNS names in section 3.1.3.1 below, with the exception that no wildcard matching is allowed. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to provide subjectAltName values instead.
Does this work?
Roger
|