Subject: [certid] version -11

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Nov 2010 18:19:53 -0700

Jeff and I just posted version -11 of the server-id-check spec, based on
list feedback from Jim Schaad and Eddy Nigg, discussions at IETF 79 last
week, and a further review by our sponsoring AD. The diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-saintandre-tls-server-id-check-11

Next we expect that Alexey will issue a second IETF Last Call on this
I-D, given the substantive changes since -09 and the fact that the first
Last Call labelled the intended state of the spec as Proposed Standard,
not Best Current Practice.

Thanks for your continued attention to this work.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Nov 2010 09:46:39 -0800

I have read the diff and believe that the new draft is ready for publication (or at least for sending to the IESG). One technical issue was introduced however:

- The sentence that was added to 2.3 beginning with "However..." needs clarification.
Current:
   However, the Common Name might contain a human-readable string for
   the service, rather than a string whose form matches that of a fully-
   qualified DNS domain name:

Proposed:
   However, the Common Name might contain a human-readable string for
   the service, rather than a string whose form matches that of a fully-
   qualified DNS domain name, and a certificate with such a Common Name
   SHOULD have a subjectAltName that contains the fully-qualified domain
   name:

A few editorial-only comments that might or might not elicit a -12:

- A parenthetical sentence was added to the beginning of 1.5 that is, fortunately, not true. The "$" thing in the security terms RFC is distracting, and would make this document harder to read. Please just remove the parenthetical sentence.

- The three examples added to 2.3 are good, but they are in the reverse order of the sentence that introduces them.

- Paragraph and section breaks are your friend. The "Implementation Note" at the end of 2.3 is more properly "Many Implementation Notes" and probably deserves its own subsection.

- Spell check is your friend. (Hint: "automatially".)

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2010 16:27:49 -0700

On 11/26/10 10:46 AM, Paul Hoffman wrote:

> - A parenthetical sentence was added to the beginning of 1.5 that is,
> fortunately, not true. The "$" thing in the security terms RFC is
> distracting, and would make this document harder to read. Please just
> remove the parenthetical sentence.

Operator error, already removed.

> - The three examples added to 2.3 are good, but they are in the
> reverse order of the sentence that introduces them.

Too much fiddling right before submission. Corrected in the running text.

> - Paragraph and section breaks are your friend. The "Implementation
> Note" at the end of 2.3 is more properly "Many Implementation Notes"
> and probably deserves its own subsection.

Good point, will place that into a new subsection and split up the long
paragraph into smaller chunks.

> - Spell check is your friend. (Hint: "automatially".)

My wetware has an onboard spell-checker, but missed that one... ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2010 16:31:45 -0700

> paragraph into smaller chunks.

2.3.1.  Implementation Notes

   Confusion sometimes arises from different renderings or encodings of
   the hierarchical information contained in a certificate.

   Certificates are binary objects and are encoded using the
   Distinguished Encoding Rules (DER) specified in [X.690].  However,
   some implementations generate displayable (a.k.a. printable)
   renderings of the certificate issuer, subject field, and
   subjectAltName extension, and these renderings convert the DER-
   encoded sequences into a "string representation" before being
   displayed.  Because a Distinguished Name (DN) is an ordered sequence,
   order is typically preserved in the DN string representations,
   although the two most prevalent DN string representations differ in
   employing left-to-right vs. right-to-left ordering.  However, because
   a Relative Distinguished Name (RDN) is an unordered group of
   attribute-type-and-value pairs, the string representation of an RDN
   can differ from the canonical DER encoding (and the order of
   attribute-type-and-value pairs can differ in the RDN string
   representations or display orders provided by various
   implementations).  Furthermore, various specifications refer to the
   order of RDNs using terminology that is not directly related to the
   information hierarchy, such as "most specific" vs. "least specific",
   "left-most" vs. "right-most", "first" vs. "last", or "most
   significant" vs. "least significant" (see for example [LDAP-DN]).

   To reduce confusion, in this specification we avoid such terms and
   instead use the terms provided under Section 1.5; in particular, we
   do not use the term "(most specific) Common Name field in the subject
   field" from [HTTP-TLS] and instead state that a CN-ID is a Relative
   Distinguished Name (RDN) in the certificate subject that contains one
   and only one attribute-type-and-value pair of type Common Name (thus
   removing the possibility that an RDN might contain multiple AVAs of
   type CN, one of which would be considered "most specific").

   Finally, although theoretically some consider the order of AVAs
   within an RDN to have meaning, in practice that rule is not observed.
   An AVA of type CN to be valid at any position within the subject
   field.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 29 Nov 2010 22:20:37 -0500

>    An AVA of type CN to be valid at any position within the subject

The last sentence is missing a verb.

Also, I don't see how AVAs within an RDN could ever have a meaningful
order.  The RDN is a "SET OF" AVAs, i.e., unordered.  The encoding order
is not significant; in fact, it is fixed by DER.

-- 
Matt