Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)
RFC 7382

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

(Alia Atlas) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2014-07-16)
No email
send info
Thanks to all (including the IETF Trustees) who helped to discuss my Discuss.
As I understand it, the document should not change to address my copyright concerns, but the Trust will post something along the lines of...
   In addition to the rights granted under the TLP with respect to
   RFC XXX (the Template RFC), a non-exclusive, perpetual 
   license is also granted to all interested persons to make, 
   reproduce and distribute modifications to the text of the 
   Template RFC solely as expressly indicated in the Template
   RFC (i.e., to insert specific information where it is called for in
   the Template RFC).

I am happy to support this document, and hope that the Trust will follow through.

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2014-07-07)
No email
send info
Preface:

When someone uses this document to produce a CPS, what will the normative language mean once the reference to RFC 2119 is omitted? E.g., this text in Section 2.1 is not in angle brackets, so I assume it will be reproduced in every CPS: "As per the CP, certificates, CRLs and RPKI-signed objects MUST be made available for downloading by all relying parties, to enable them to validate this data." What is this kind of requirement supposed to mean when published in a CPS? (Similar question for 3.1.3).

s/employed in the RFC/employed in that RFC/

Section 1.6:
"An RPKI signed object is a digitally signed data object (other than a certificate or CRL) declared to be such by a standards track RFC"

I find the "such" here ambiguous. Something is declared to be an object by a standards track RFC? Or declared to be a digitally signed object? Or declared to be an RPKI-signed object?

(Spencer Dawkins) No Objection

Comment (2014-07-10)
No email
send info
I agree with Barry's comments.

(Stephen Farrell) No Objection

Comment (2014-07-10)
No email
send info
- 1.4.2:  Why do we need this?  I see the same is in 6484 (and
would have commented simlarly on that had I been on the IESG
then). I do not see any need for that at all but I expect that
even if I'm right you probably want it so as to be consistent
with 6484.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-07-07)
No email
send info
I think I got a bout of denseness (density?) when I read this.  It is an odd document, what with a preface that tells people to do a bunch of surgery to the document and then publish their own sorta-version of it and all.

Many thanks to the document shepherd, Chris Morrow, for explaining the bits that I found odd or confusing.  I wondered why it's a BCP.  That was easy to explain.  I wondered where these things would be published, if not RFCs, and I wondered why the huge amount of invariant text isn't just referenced, rather than being included in every CPS.  In the end, I think a small bit of explanation in the preface would have done a lot for me, so let me suggest this, as a non-blocking comment.  No need to respond to this, and do what you think best:

OLD
   This document contains a template to be used for creating a
   Certification Practice Statement (CPS) for an Organization that is
   part of the Resource Public Key Infrastructure (RPKI). (Throughout
   this document the term "organization" is used broadly, e.g., the
   entity in question might be a business unit of a larger
   organization.) The user of this document should:

     1. substitute a title page for page 1 saying, e.g., "<Name of
        Organization> Certification Practice Statement for the Resource
        Public Key Infrastructure (RPKI)" with date, author, etc. There
        is no expectation that a CPS will be published as an RFC.
NEW
   This document contains a template to be used for creating a
   Certification Practice Statement (CPS) for an Organization that is
   part of the Resource Public Key Infrastructure (RPKI). (Throughout
   this document the term "organization" is used broadly, e.g., the
   entity in question might be a business unit of a larger
   organization.)

   There is no expectation that a CPS will be published as an RFC.
   Instead, the CPS will be published in ways similar to how such
   things as privacy policies and terms of service are published: as
   pages on the organization's web site and the like.  Organizations
   are expected to use this template as a best current practice,
   rather than creating their own from scratch -- this document
   contains both invariant text that will appear in all Certification
   Practice Statements and places to fill in text that's specific to
   the CPS being created.

   The user of this document should:

     1. substitute a title page for page 1 saying, e.g., "<Name of
        Organization> Certification Practice Statement for the Resource
        Public Key Infrastructure (RPKI)" with date, author, etc.
END

Of course, if you choose to accept this suggestion you should tweak the text of that paragraph appropriately: I'm sure I didn't get everything exactly right.

(Ted Lemon) No Objection

Comment (2014-07-10)
No email
send info
My brain stumbled on the following text in 1.3:
   Describe how the registration authority function is handled for the
   CA(s) that you operate.  The RPKI does not require establishment or
   use of a separate registration authority (RA) in conjunction with the
   CA function.

What is the second sentence intended to address?   I read it as meaning something like "The RPKI allows the RA to be operated either in conjunction with the CA function, or through a separate registration entity."   But the subsequent sentences suggest that this is incorrect.   So if it means the opposite of what I read, it should be stated directly so that it's clear what it means.  E.g., "The RPKI does not allow for the establishment or use of a separate RA in conjunction with the CA function."

In 3.1.5:
   Although it is desirable that these
   subject names be unique throughout the PKI, to facilitate certificate
   path discovery, such uniqueness is neither mandated nor enforced
   through technical means.

I think you mean the two clauses at the end of the sentence to be distinct, but they read as expressing a single meaning.   It might be clearer to say it this way:

   Although it is desirable that these
   subject names be unique throughout the PKI, to facilitate certificate
   path discovery, such uniqueness is not required, nor is it enforced
   through technical means.

In 4.4.1:
   Any subscriber in good standing who holds INRs distributed by <Name

What does "in good standing" mean?    If this phrasehas a specific meaning, a reference would be helpful.   If it doesn't, it has so many possible meanings that I think it might be better to use a more specific phrase.   Or if it is simply whatever the policy of <Name of Organization> is for "in good standing," it would be good to make that explicit, since at least my tendency is to take it as having a common global meaning.

In 8:

   List here any audit and other assessments used to ensure the
   security of the administration of INRs. These are sufficient for the
   RPKI systems.

Does the second sentence mean that what is stated in the first sentence is all that is required, or that what is stated must be sufficient for RPKI systems?   I can't come up with a clear meaning for this sentence.

Despite my carping, this is a great document, and I'm glad to see it go by.   Thanks for doing it!

(Kathleen Moriarty) No Objection

Comment (2014-07-09)
No email
send info
Having written an extensive CP and CPS for an organization, this template looks very good and appears to meet the expectations of users for a template such as this.  Thank you for your effort on this draft.