Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-cp-17

[Ballot comment]
Some comments from Ari Keränen:

4.6.7. Notification of certificate issuance by the CA to other entities

  No additional stipulations beyond those of section 4.3.3.

There's no section "4.3.3" in this document; I'd assume you mean "4.4.3" (same problem in sections 4.7.7 and 4.8.7).


13. References

Missing RFC5736 reference (mentioned in Section 1.1.)

[Ballot comment]
I have No Objection to the publication of this document, but there are
a couple of nits I hope the authors will attend to before publication.

---

Missing close parenthesis in the document title.

---

In the Introduction...

  Note: This document is based on the template specified in the
  Internet Engineering Task Force (IETF) standards document RFC 3647
  [RFC3647].  In the interest of keeping the document as short as
  reasonable, a number of sections contained in the template are
  omitted from this policy because they did not apply to this PKI.
  However, we have retained the section numbering scheme employed in
  the RFC to facilitate comparison with the outline in Section 6 of
  the RFC. Each of these omitted sections should be read as "No
  stipulation" in CP/CPS parlance.

In the interestes of disambiguity (for example, once this document
has been published as an RFC) could you please
s/the RFC/RFC 3647/
both times it shows.

---

1.5.4. CP approval procedures

  The IESG MUST approve a replacement BCP that either updates or
  obsoletes this BCP, following the procedures of the IETF Standards
  Process as defined in RFC 2026 [RFC2026].

This is a little amusing. But I think you actually mean...


  Any BCP that either updates or obsoletes this BCP, MUST be approved
  by the IESG following the procedures of the IETF Standards Process as
  defined in RFC 2026 [RFC2026].

---

3.1.2. Need for names to be meaningful

  The Subject name in each certificate SHOULD NOT be "meaningful",
  i.e., the name is NOT intended to convey the identity of the Subject
  to relying parties.

While I understnd the desire for stress, I think s/NOT/not/

---

3.1.3. Anonymity or pseudonymity of subscribers

  Although Subject (and Issuer) names need not be meaningful, and may
  appear "random," anonymity is not a function of this PKI, and thus
  no explicit support for this feature is provided.

Unless there is some special meaning of "pseudonimity" in the security
community, I would suggest dropping it from the section title. The
section text does not discuss the use of pseudonyms, and (to me) the
use of a pseudonym is destinct from annonymity.

---

3.1.5

s/Subject names/subject names/ at least twice

[Ballot comment]
A few nits:

Abstract: s/Internet resource/Internet Number Resource/

Introduction: s/Internet number resource/Internet Number Resource/

In section 2.4, should this text use RFC 2119 terms:

  This data is supposed to be accessible to the public.

Why are sections 5.1.*, 5.2.* listed as sections with no text?

[Ballot comment]
4.10. Certificate status services

  This PKI does not make provision for use of OCSP or SCVP, because it

Informative references are needed here.

  is anticipated that the primary RPs (ISPs) will acquire and validate
  certificates for all participating resource holders.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Certificate Policy (CP) for the Resource PKI (RPKI) to BCP


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Certificate Policy (CP) for the Resource PKI (RPKI'
  as a BCP

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 2011-02-21. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-cp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-cp/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Sandra Murphy, sidr co-chair.  The document
shepherd has personally reviewed the document.  No issues were
discovered that would prevent advancement.  This document is ready
for forwarding to the IESG.

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

The document has received adequate review from both key WG members and
key non-WG members.  The document was presented to the working group
at the IETF71, IETF73, IETF74, IETF75, IETF76, IETF77, IETF78 and IETF79
meetings.  Additionally, RIRs have reviewed this document.  There
are no concerns regarding the depth or breath of the reviews that
have been performed.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no specific concerns to highlight to the AD or IESG. 
No IPR disclosures have been filed related to this document.

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

The document underwent two WGLCs: one in late 2009 and another that
began in August, 2010. These WGLCs elicited comments from key WG
members, and several others with PKI experience. Changes were made to
address the issues raised by these comments. Because this a 40-page
document (despite effort to minimize its length), and because much of it
is procedural in nature, it is probably fair to assume that not all WG
members have elected to review the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts
Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.  The tools site reports:

    Summary: 0 errors (**), 2 warnings (==), 6 comments (--).

The warnings have to do with the copyright year and a missing reference.

The comments have to do with possible downrefs, as many of the
references are not yet RFCs.  This document is intended as a BCP.

There are no formal reviews required for this document.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References have been split into normative and informative sections.

This document relies normatively on several other working group
documents that are either advancing at the same time or have been
through last call and are awaiting final versions addressing
minor comments in order to advance.

This document is intended to be BCP.  Several of the normative
references are Standards track, one is to be Informational.  The
question is whether that constitutes a downward reference.  The
idnits tool warns of the potential downref.

This question is under discussion with the routing ADs.

There's reason not to delay publishing this draft, even so.  By X.509
standards, there's a field in each certificate that points to the policy
that governs it.  In the RPKI case, that field MUST point to the
policy in this draft and no other.  (The RPKI is very different from
other PKIs in that respect.)  So this draft should be published for
RIRs and other CAs to have a reference for the policy they include
in their certificates.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section exists.  There are no IANA
considerations for this document.  No registries are defined or amended.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

This document uses ASN.1 in mentioning the object identifier for the
CP.  The syntax was checked using asn1Parser from the
libtasn1-tools package (v2.7.1) and passed.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

Technical Summary

The document is a Certificate Policy (CP) for the Resource PKI. It
follows the format established for document of this type, in RFC 3647.
It is customary for a large scale PKI to publish an associated CP.
In the case of the RPKI, this CP describes essential, common aspects
of CA operation, both as guidance to CAs and for the benefit of all
relying parties (RPs). The CP defers many details of Certification
Authority (CA) procedures to the Certification Practice Statement
(CPS) that will be published by most CAs that operate in the RPKI
context. (Not all CAs need to publish a CPS; a CA that issues
certificates only to entities within the same administrative realm
as the CA need not generate or publish a CPS.)

Working Group Summary

An early review was provided by the NRO (the RIRs), and, as a result,
the document was reduced in length. A PKI expert (formerly with
VeriSign Japan, now with IANA) provided extensive comments, as did
Sean Turner, the cognizant security AD.

Document Quality

The document is well written and clear. It does not describe a
protocol, so there are no "implementations" per se. However, at least
four RIRs have developed CPS's that are based on the CP. There is no
MIB, and no Media Types are involved. However, as noted above more than
one PKI expert has reviewed the document.