A few more comments about draft -04: > 2.1. Subject Naming in PKIX Certificates > [...] > "string representation" of a DN before being rendered. Often such a > DN string representation is ordered from left-to-right, most specific > to most general. See [LDAP-AUTH] for details.
I would suggest to replace this with a reference to RFC 4514 (not 4513). > 2.2. PKIX Certificate Name Rules > > The following rules apply to the representation of application server > identities in PKIX certificates issued by certification authorities. > > 1. The certification authority MUST issue the certificate based on > the DNS domain name (not an IP address) at which the server will > provide the relevant service. With the current draft, "relative" domain names (such as "www", "mail" etc.) are also permitted as DNS-IDs or CN-IDs, from what I understand. Is this a deliberate decision, or should domain names possibly be required to be fully qualified (or "absolute", in RFC-1034 speak)? If the latter, then it would probably make sense to add an entry for "DNS domain name" to section 1.3 and explicitly state that it's required to be absolute / fully qualified. > 3.3. Seeking a Match > > Once the client has constructed its order list of reference > identifiers and has received the server's presented identifiers in > the form of an PKIX certificate, the client checks its reference Nit: "a PKIX certificate" > Note: A client MUST NOT seek a match for a reference identifier of > CN-ID if the presented identifiers include an SRV-ID, URI-ID, > DNS-ID, or any application-specific subjectAltName extensions, and > MUST NOT check a Common Name in the certificate if it is other > than the last Relative Distinguished Name (RDN) in within the > sequence of RDNs making up the Distinguished Name within the > certificate's subjectName. As already mentioned elsewhere, this requirement is probably too strict. I suggest changing to something like "must only check against the last Common Name RDN in the sequence of RDNs making up the Distinguished Name within the certificate's subjectName". > 3.4.4. Checking of DNS Domain Names in Common Names > > As noted, a client MUST NOT seek a match for a reference identifier > of CN-ID if the presented identifiers include an SRV-ID, URI-ID, > DNS-ID, or any application-specific subjectAltName extensions. > > Therefore, if and only if the identity set does not include > subjectAltName extensions of type dNSName, SRVName, or > uniformResourceIdentifier (or any application-specific subjectAltName > extensions), the client MAY as a fallback check for a DNS domain name > in the value of the last Relative Distinguished Name (RDN), if it is > of type Common Name (CN), within the sequence of RDNs making up the > Distinguished Name within the certificate's subjectName. (Note: The > term "last" refers to the DER order, which is often not the string > order presented to a user; the order that is applied here MUST be the > DER order.) See above - should be adapted accordingly. > 4.3. Internationalized Doman Names -> "Domain" Kaspar _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
