Skip to main content

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5280

Yes

(Sam Hartman)

No Objection

Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)

Recuse

(Russ Housley)
(Tim Polk)

Note: This ballot was opened for revision 11 and is now closed.

Lars Eggert
No Objection
Sam Hartman Former IESG member
Yes
Yes ()

                            
Chris Newman Former IESG member
No Objection
No Objection (2008-01-10)
---
      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.
Cullen Jennings Former IESG member
No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
David Ward Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection ()

                            
Jon Peterson Former IESG member
No Objection
No Objection ()

                            
Lisa Dusseault Former IESG member
No Objection
No Objection ()

                            
Magnus Westerlund Former IESG member
No Objection
No Objection ()

                            
Mark Townsley Former IESG member
No Objection
No Objection ()

                            
Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
Recuse
Recuse ()

                            
Tim Polk Former IESG member
Recuse
Recuse ()