Re: [certid] version -11

[Peter Saint-Andre <[e-mail]>]

On 11/29/10 4:27 PM, Peter Saint-Andre wrote:
> On 11/26/10 10:46 AM, Paul Hoffman wrote:
>
>> - 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.

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.