Subject: Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)

From: Christopher Morrow <[email-masked]>
Date: Fri, 1 Mar 2013 11:36:36 -0500

Great... so assuming the authors deal with this set of comments we'll
ask them to spin a new version and submit that for WGLC when it
arrives?

Does that seem like a good path for those still listening?

-chris
co-chair-1-of-3

On Thu, Feb 28, 2013 at 9:30 AM, Sean Turner <[email-masked]> wrote:
> Below are some comments on the draft.  I also submitted my nits to the
> editors.
>
> 0) Based on the assumption that draft-newton-sidr-policy-qualifiers will be
> adopted because that's what the RIRs want should s1.2 or 1.5 also include
> some information about where it can be found?  This information would be
> identical to the URI included in the policy qualifier?
>
> 1) s1.6: CP - Is it worth nothing that there might be another CP for the
> BPKI?
>
> 2) s4.6.1: Not sure if this needs to go here but don't we need to say
> something about not renewing certificates forever?
>
> 3) draft-ietf-sidr-rtr-keying describes the procedures for operator
> generated keys (i.e., those that are not router generated).  A couple of
> questions come to mind:
>
> a) Should the CPS point to that draft in s6.1.2 or will the CPS be updated
> when draft-ietf-sidr-rtr-keying is published?
>
> b) draft-ietf-sidr-rtr-keying allows operators sign the private keys they
> generate and subsequently send back to the router.  Should this be
> explicitly called out in s4.5.1.  For s.4.5.2, is the returned signed-key an
> RPKI-Signed Object?
>
> spt
>
>
> On 2/21/13 11:30 PM, Chris Morrow wrote:
>>
>> WG folks,
>> As the subject states, let's please start a WGLC poll for the document:
>>     draft-ietf-sidr-cps-01
>>     <http://tools.ietf.org/html/draft-ietf-sidr-cps-01>
>>
>> with the abstract:
>>    "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), e.g., a
>>     resource allocation registry or an ISP."
>>
>> So far the authors have made a few revisions, with updates based on
>> comments/feedback, at this time the document has been stable for more
>> than 6 months time, let's move this along if there are no further
>> issues/addendums/questions/appendixes.
>>
>> thanks!
>> -chris
>> co-chair-1-of-3
>> _______________________________________________
>> sidr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidr
>>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sean Turner <[email-masked]>
Date: Mon, 04 Mar 2013 11:08:29 -0500

Sounds like a plan to me.

spt

---

From: David Mandelberg <[email-masked]>
Date: Mon, 04 Mar 2013 18:16:37 -0500

Overall this looks good. I found one minor issue and a bunch of nits,
and I have some questions:

= minor =

4.6.7. Notification of Certificate Issuance by the CA to Other Entities:
There is no section 4.4.3.

= questions =

1.5.1. Organization administering the document: Should the address
and/or website of the organization also be included? That could help
disambiguate when there are multiple organizations with the same or
similar names.

4.1.2. Enrollment Process and Responsibilities: I found the second
sentence unclear. Are you trying to tell registries and ISPs that
certificates should be issued as part of their normal business
practices? Are you trying to say that *if* certificates are issued as
part of normal business practices *then* "a separate application to
request a certificate may not be necessary"?

4.6.1. Circumstance for Certificate Renewal: The phrase "unless the
private key has been reported as compromised" doesn't specify how a
compromised key can be reported. Should there be a reference to section
4.9.3?

4.7.1. Circumstance for Certificate Re-key: What Certificate Policy is
"Section 5.6 of the Certificate Policy" referring to? Section 5.6 of
RFC6484 doesn't mention validity intervals.

5.4.1. Types of Events Recorded: Why aren't "Key generation", "Software
and/or configuration updates to the CA", and "Clock adjustments" listed?

5.6. Key Changeover: Does mention of validity intervals belong in this
section?

= nits =

Multiple places: Should "the RPKI CP" be changed to "[RFC6484]"?

Preface: item 5 lists "Acknowledgments" three times (twice as
"Acknowledgments", once as "12").

1. Introduction: "(INRs, see definition in Section 1.7)" references a
non-existent section 1.7.

1.1. Overview: Change "as described in 2.4" to "as described in Section
2.4".

1.4.1. Appropriate Certificate Uses: Change "2.4" to "Section 2.4".

2.2. Publication of Certification Information: Should the hyphen in
"RPKI-signed objects" be changed to a space?

2.3. Time or Frequency of Publication: Change "nextScheduledUpdate" to
"nextUpdate".

3.1.2. Need for Names to be Meaningful: The first two sentences seem
redundant with section 3.1.5.

3.2.6. Criteria for Interoperation: Change "e g." to "e.g.".

4.1.1. Who Can Submit a Certificate Application: Should "this
Organization" be changed to "<Name of Organization>"?

4.2.2. Approval or Rejection of Certificate Applications: Change "3.2.1"
to "Section 3.2.1".

4.4.2. Publication of the Certificate by the CA: Insert space in
"notified>.<Describe".

4.6.4. Notification of New Certificate Issuance to Subscriber: Change
"4.3.2" to "Section 4.3.2".

4.7.2. Who May Request Certification of a New Public Key: Change "or" in
"holder or a certificate" to "of".

4.9.7. CRL Issuance Frequency: Change "nextScheduledUpdate" to
"nextUpdate".

5.7. Compromise and disaster recovery [OMITTED] and 5.8. CA or RA
Termination: These section numbers don't match up with rfc 6484.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 4 Mar 2013 15:40:29 -0800

I'll go along with that. 

I'm not seeing any major structural alterations to the draft (at this stage) by doing that. 

Cheers,
Terry

---

From: Sean Turner <[email-masked]>
Date: Mon, 04 Mar 2013 18:56:56 -0500

I guess I should have also said that I support moving this draft down 
the path towards publication.

spt

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 4 Mar 2013 21:46:35 -0500

On Mon, Mar 4, 2013 at 6:56 PM, Sean Turner <[email-masked]> wrote:
> I guess I should have also said that I support moving this draft down the
> path towards publication.
>

I got that :) I am/was/am waiting for the next rev to pop into the tracker.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Mar 2013 15:58:49 -0500

> There is no section 4.4.3.
fixed.
> disambiguate when there are multiple organizations with the same or
reworded to include these additional pieces of info.
> request a certificate may not be necessary"?
the text is saying that an org allocating INRs is already establishing a
relationship with the subject, and thus need not repeat that process when
it issues an RPKI cert.
> compromised key can be reported. Should there be a reference to section
added forward pointer.
> RFC6484 doesn't mention validity intervals.
The CP used to refer to this validity interval issue, but
it later changed, as did the admonition. We'll delete the paragraph.
> Multiple places: Should "the RPKI CP" be changed to "[RFC6484]"?
sure.
> "Acknowledgments", once as "12").
fixed.
> non-existent section 1.7.
changed to 1.6
> 1.1. Overview: Change "as described in 2.4" to "as described in Section
fixed.
> 1.4.1. Appropriate Certificate Uses: Change "2.4" to "Section 2.4".
fixed
> "RPKI-signed objects" be changed to a space?
yes, fixed.
> 2.3. Time or Frequency of Publication: Change "nextScheduledUpdate" to
fixed.
> redundant with section 3.1.5.
removed redundant sentences.
> 3.2.6. Criteria for Interoperation: Change "e g." to "e.g.".
fixed.
> Organization" be changed to "<Name of Organization>"?
reworded.
> 4.2.2. Approval or Rejection of Certificate Applications: Change "3.2.1"
fixed
> 4.4.2. Publication of the Certificate by the CA: Insert space in
fixed.
> "4.3.2" to "Section 4.3.2".
fixed.
> "holder or a certificate" to "of".
fixed.
> 4.9.7. CRL Issuance Frequency: Change "nextScheduledUpdate" to
fixed.
> Termination: These section numbers don't match up with rfc 6484.
Whoops. the CP lost an [OMITTED] subsection # here. "CA or RA 
Termination" is supposed to be 5.8, not 5.7.
so the CPS is correct, re alignment with RFC 3647. Guess we'll have to 
issue an editorial errata for the CP.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Mar 2013 16:11:47 -0500

Sean,

Thanks for the review.
> 0) Based on the assumption that draft-newton-sidr-policy-qualifiers 
> will be adopted because that's what the RIRs want should s1.2 or 1.5 
> also include some information about where it can be found? This 
> information would be identical to the URI included in the policy 
> qualifier?

> 1) s1.6: CP - Is it worth nothing that there might be another CP for 
> the BPKI?
I added the following ext:

If a BPKI is employed by a CA, it may have its own CP, separate from the 
RPKI CP.

> something about not renewing certificates forever?
I am reluctant to point out one example of a bad PKI practice, when 
there are so many more ...
> generated keys (i.e., those that are not router generated). A couple 
> of questions come to mind:
>
> a) Should the CPS point to that draft in s6.1.2 or will the CPS be 
> updated when draft-ietf-sidr-rtr-keying is published?
We could update the CPS with a pointer to rtr-keying when it is 
published. It would be a very minor update,
as an informational reference. If the chairs prefer, we can add a 
reference to the I-D, and have this doc held
in the RFC Editor's queue waiting for that doc to be approved.
> b) draft-ietf-sidr-rtr-keying allows operators sign the private keys 
> they generate and subsequently send back to the router. Should this be 
> explicitly called out in s4.5.1. For s.4.5.2, is the returned 
> signed-key an RPKI-Signed Object?
The first comment does not seem to apply to 4.5.1/2. Could you clarify?

The returned signed-key is not an RPKI signed object, as defined in RFC 
6488. Such objects are stored in the
repository system, not just passed between a local operator's system and 
a router.

Steve

---

From: Sean Turner <[email-masked]>
Date: Thu, 07 Mar 2013 08:24:35 -0500

> If a BPKI is employed by a CA, it may have its own CP, separate from the

wm

> there are so many more ...

When you put it that way :)

> in the RFC Editor's queue waiting for that doc to be approved.

wfm

> The first comment does not seem to apply to 4.5.1/2. Could you clarify?

Yep you're right it doesn't apply.

> repository system, not just passed between a local operator's system and

ack

Thanks for dealing with these.

spt