Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5280
Note: This ballot was opened for revision 11 and is now closed.
(Sam Hartman) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
Lars Eggert No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
Comment (2008-01-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
--- An explicitText field includes the textual statement directly in the certificate. The explicitText field is a string with a maximum size of 200 characters. Conforming CAs SHOULD use the UTF8String encoding for explicitText, but MAY use IA5String. --- Just saying IA5String or UTF8String is not sufficient for interoperability as no guidance is provided for use of NUL, line break semantics or other problematic control characters that are permitted in these syntaxes. draft-klensin-net-utf8 (presently in IETF last call) would provide a reference to flesh out interoperability for these text strings. I recommend adding that reference (either normatively or informatively) to improve the document. name) extension MUST be used; however, a DNS name MAY be represented in the subject field using the domainComponent attribute as described in section 4.1.2.4. I'm not convinced this accurately reflects practice. I've never seen dc components used to represent a domain in a certificate. When I've seen them used in LDAP, they represent the DIT location for domain-related attributes, something quite different from the domain name itself. However, I've frequently seen a domain encoded in a certificate subject as the value of the "CN=" attribute and TLS software failing to support that may not interoperate well. Support for domain in CN is a MUST in the widely deployed RFC 2818. I'm not sure it's wise to mention a third encoding of domain in certificates when support for two encodings is already needed by real-world implementations. the address MUST be stored in the rfc822Name. The format of an rfc822Name is an "addr-spec" as defined in [RFC 2822]. An addr-spec It's generally better to refer to RFC 2821 for the syntax of email addresses. However given the unfortunate name of this field, I instead recommend you add a sentence that discourages use of comments, folding whitespace and obsolete syntax that RFC 2822 permits in an addr-spec as none of those features will interoperate well in this context. Note that an addr-spec has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". The second clause of this sentence is not correct. RFC 2822 addr-spec ABNF does permit comments at the end (as well as at the beginning and on either side of the '@' sign). Implementations should convert IRIs to Unicode before display. Specifically, conforming implementations should perform the conversion operation specified in section 3.2 of [RFC 3987]. Typo, where this says "IRIs" it meant to say "URIs". Q: is lower case should intentional here? I have reviewed section 7 and consider it sufficient otherwise.