On 5/13/10 2:28 AM, Kaspar Brand wrote: > A few more comments about draft -04:
My apologies, I missed this post while making our edits for -05. (Nits skipped in what follows.) >> 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). Corrected. >> 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. Our intent was to cover only absolute domain names. Fixed in our working copy. >> 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". That wording does seem better. Thanks for the text. >> 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. Done in our working copy. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
