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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
