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

[Ballot comment]
---
      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.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

I reviewed this I-D and  I feel is it ready for publication, modulo minor copy editing improvements. Stefan Santesson, my co-chair, is an author and thus he did not participate in this review.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

This document has undergone a VERY thorough review by the WG.  This document is an update of the certificate and CRL profile that is the cornerstone standard for use of X.509 technology in the IETF. The update was motivated by the need to track IETF support for internationalized names, discovery of several minor errors in 3280, and by the need for clarifications to the text based on experience with the interpretation of RFC 3280. All of the major contributors to PKIX have contributed to and or commented on this document.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

WG consensus is solid. As usual there are a couple of folks who would like to make even more, minor changes, but the WG believes that we have worked on this version long enough and it is time to publish.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The I-D was processed using the idnits program. It identified 1 error ( an obsolete normative reference) and seven warnings, all of which will be easy to fix.  There were also 15 comments; most appear to have been erroneously triggered by the ASN.1.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

The document contains both types of references, and they are clearly labeled. All normative  references cite RFCs or ISO standards (necessary since this document is a profile of ISO standards).

Document Write-up

Technical Summary

This document is a replacement for RFC 3280, the standard that profiles X.509 certificate and CRL syntax for use in the IETF. RFC 3280 needed to be updated to track IETF support for internationalized names, to correct errors that have been discovered since the publication of 3280 five years ago. As part of the update, the specification of the AIA certificate extension (an IETF "private" extension) was incorporated into the document, instead of being a standalone RFC. (4325). The document also updates the reference to the list of supported algorithms used with certificates. The authors made a minor modification to the text to make clear that hash algorithms other than SHA-1 can be used in certain places, consistent with Security Area policy to make all of our standards independent of specific hash algorithms. The security considerations section was expanded, to cal attention to more subtle (DoS) concerns that may arise in some contexts. Despite the numerous tweaks and fixes,  most of the text in this document is unchanged form 3280. The end of the introduction section  of this document clearly summarizes the differences between it and RFC 3280.

Working Group Summary

The working group expressed consensus to advance the draft to Proposed Standard.

Protocol Quality

This document has been reviewed by members of the ietf-pkix@imc.org mailing list and by the working group chairs. The updated spec is a needed improvement over 3280 and should be published.