Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
draft-ietf-pkix-rfc3280bis-11

---
      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.