Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
draft-ietf-pkix-rfc5280-clarifications-11

[Ballot comment]
Section 3:

    Conforming CAs SHOULD use the
    UTF8String encoding for explicitText, but MAY use VisibleString or
    BMPString.

This is (as was 5280) worded oddly. I can take this to either mean, "UTF8String is the requirement. However, there are circumstances under which you might violate this requirement, in which case VisibleString or BMPString are the only possible alternatives", or "Any one of UTF8String, VisibleString, or BMPString are acceptable, but UTF8String is preferred." The combination of SHOULD and MAY makes this ambiguous. I think you should fix it.

[Ballot comment]

  Please consider the Gen-ART Review comments from Vijay Gurbani on
  16-Oct-2012:

  - S1: The fourth paragraph should be put right underneath the second
  paragraph since the former continues discussion started by the latter.

  - S1: Last paragraph -- it will be good to provide some documentation
  regarding the "observed attacks".  Especially a link to relevant
  papers of archival quality discussing the attacks will be helpful.  If
  the attacks are related to the Diginotar and Comodo break-ins, then
  there is an archival paper [1] at a reasonably high level from IEEE
  that discusses this and provides a starting point for those who want
  to learn more.

  [1] Neal Leavitt, "Internet security under attack: The undermining of
      digital certificates," pp. 17-20, IEEE Computer, December 2011.

[Ballot comment]
I'm glad to see these clarifications, and I'm happy to ballot "yes".  A few notes, and one question I'd appreciate an answer to, if you don't mind:

Notes:

I would have appreciated the use of proper change bars on the paragraphs.  When one sentence in a paragraph is changed, it's hard to pick out what changed -- I wind up having to read the old and new paragraphs back and forth, one sentence or one phrase at a time.  Harder than it needs to be, and especially bad when there's gratuitous moving of words from one line to another (as in Section 4).  That made this difficult to review.

-- Section 9 --
The RFC Editor will likely change "versions 00 through 04" to "earlier versions"; they don't like to refer to specific versions of drafts like that.  If you really don't want that change, you might have to fight them on it.

Question:

-- Section 3 --
This changes "MAY use IA5String" to "MUST NOT" use IA5String.  This makes some formerly conforming CAs non-conforming... what is the effect of this in actual practice?  Are there known CAs that are using IA5String?

[Ballot comment]

Glad to see we've finally got this done. Thanks to all involved.
All of the updates seem correct and appropriate to me.

While there might be other things  about 5280 that one could
consider wanting to update, at this point there would likely be
sufficient difficulty in achieving rough consensus on any such
addition that its simply not worth the effort.

Actually, because the -08 and -10 version are identical (modulo the version # and dates) I'll not waste the IETF's time and put it on the 10/25 agenda.

This draft was returned to the WG after IETF LC completed to give the WG a chance to discuss some additional text about CRL entry extensions.  Proposed text was incorporated into the -09 version, but the WG was unable to come to consensus and the text was removed from the -10 version.  So, the draft being last called on 10/15 is the same as -08 draft that originally entered IETF LC on 08/22.

IANA has reviewed draft-ietf-pkix-rfc5280-clarifications-08, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Updates to the Internet X.509 Public Key Infrastructure Certificate
  and Certificate Revocation List (CRL) Profile'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-09-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 5280, the Internet X.509 Public Key
  Infrastructure Certificate and Certificate Revocation List (CRL)
  Profile.  This document changes the set of acceptable encoding
  methods for the explicitText field of the user notice policy
  qualifier and clarifies the rules for converting internationalized
  domain name labels to ASCII.  This document also provides some
  clarifications on the use of self-signed certificates, trust anchors,
  and some updated security considerations.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/ballot/


No IPR declarations have been submitted directly on this I-D.

For the Apps Folks (ADs and APPSDIR review team) :

1) WRT the changes in s3 of the draft: The first two sentences have been around since RFC 2459, but the remaining sentences were added when 5280 was published.  In a nutshell, this change brings some reality to the spec because this is what issuers actually do - though honestly I personally wish they'd follow the recommendation earlier in the paragraph that says only use the OID and don't use these fields s this wouldn't be an issue (but that's just my two cents).

2) WRT the changes in s5 of the draft: Read the last sentence of the proposed change 1st ;)  This is not about updating the IDNA to be '08 compliant, it's about internal alignment with the existing text in s7.2 of RFC 5280.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Standards track. This document UPDATEs RFC 5280.

Is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement

Write-Up. The approval announcement contains the following sections:


Technical Summary

Since the publication of RFC 5280 in May of 2008, several areas have
been identified where the document was not clear, thus motivating a
“clarifications” update. Experience with CA use of the Certificate
Policies extension motivated a change to allow (MAY) use of BMPString.
The DANE WG requested that PKIX clarify make an explicit (positive)
statement about self-signed certificates that are not marked as CA
certificates. PKIX published an informational RFC (5937) and a standards
track RFC (5914) related to trust anchor formats and constraints
processing by a relying party. This document updates 5280 to point to
these documents. Experience with IDNs motivated a minor update to align
the details of how such names are processed. The Secruity Considerations
section was updated to reflect experience with attacks against CAs. This
document addresses all of these issues.


Working Group Summary

Most of the clarifications in this document were not contentious, except
for the self-signed certificate text. Numerous revisions were required
to develop text that was acceptable to the WG. The original document
editor was replaced as part of this process. He elected to no longer be
listed as an author, but he is thanked in the Acknowledgements section.


Document Quality

This is a very small document and is well written. Most of the
clarifications are motivated by experience with existing implementations
of CA or RP software. There is no need for a MIB doctor review, there
are no Media Types, etc.

Personnel

Steve Kent is the Document Shepherd, and Sean Turner the Responsible
Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

I read and edited the document, working in conjunction with the current
document editor.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I have no technical concerns with respect to this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

I contacted the author and he confirmed that there are no relevant IPR
disclosures, to the best of his knowledge.

(8) Has an IPR disclosure been filed that references this document?

Not to the best of my knowledge, based on a check of the IETF IPR
disclosure database.

(9) 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?

Because of the self-signed certificate text, this was a contentious
document. But, at this point, all of the folks who have actively
discussed this text appear to be willing to live with what we have.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

I am aware of no threatened appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

I processed version 8 of this document with I-D nits (verbose mode) and
there were no errors.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no MIB, and no media types definitions in this document. Only
example URIs are employed, and they are simple types of URIs.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

No.

(15) Are there downward normative references (see RFC 3967)?

There are no down references.

(16) Will publication of this document change the status of any existing
RFCs?

Yes, this updates RFC 5280.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A.