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

From: Chris Morrow <[email-masked]>
Date: Thu, 21 Feb 2013 23:30:29 -0500

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

---

From: Terry Manderson <[email-masked]>
Date: Wed, 27 Feb 2013 20:48:56 -0800

Apologies for taking so long to review this document.

This is a well constructed template and I have only 6 concerns to be
addressed.

1) My first observation is that the CPS takes an organisational view (and
that is expected) of the RPKI CA's in action, and while it certainly
provides allowances for multiple CA's within an organisation (s 1.3.1)
There are situations that the 'organisation' will have different
personalities. To which I would like "organisation" to also explicitly
include wording that includes 'business unit.'

2) In section 1.3.5, "Specify the entity that operatesŠ" Entity should
most definitely be plural. Yes, I accept that is a little(?) picky.

3) Nit: Section 1.6 Page 11. There appears to be an extra "<tab>-" in the
definition if ISP, NIR, and RPKI-signed object.

4) Section 2.1 "via RSYNC". Can that be adjusted to "standardised
mechanisms supported by RPKI"? or something similar?

5) In section 4.1.1, can "Any subscriber who holds..", be amended to "Any
vetted and approved subscriber who holds.."

6) Can you explain why compromise and disaster recovery (s5.7) was omitted
from the template?

Cheers
Terry

On 22/02/13 2:30 PM, "Chris Morrow" <[email-masked]> wrote:

>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Feb 2013 01:26:20 -0500

Terry,

Thanks for the feedback. Below are responses to your comments.

> include wording that includes 'business unit.'
How about the following revision to the preface:

    This document contains a template to be used for creating a

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.)_
> 2) In section 1.3.5, "Specify the entity that operatesS(" Entity should

<Specify _one or more entities that operate_ a repository holding 
certificates,

CRLs, and other RPKI-signed objects issued by this Organization, and

provide a URL for the repository.>

> definition if ISP, NIR, and RPKI-signed object.
fixed.
> mechanisms supported by RPKI"? or something similar?

The <Name of Organization> RPKI CA will publish certificates, CRLs,

and RPKI-signed objects via a repository that is accessible via

<insert SIDR-designted protocol name here>at <insert URL here>. This 
repository will
    conform to the structuredescribed in [RFC6481].

> vetted and approved subscriber who holds.."

    Any subscriber _in good standing_ who holds INRs distributed by this
    Organization may submit a certificate application to this CA.

> 6) Can you explain why compromise and disaster recovery (s5.7) was omitted
5.7. Compromise and disaster recovery

<Describe your plans for dealing with CA key compromise and how you

plan to continue/restore operation of your RPKI CA in the event of a 
disaster.>

Steve

---

From: Terry Manderson <[email-masked]>
Date: Thu, 28 Feb 2013 16:37:29 +1000

Hi Steve,

I appreciate the very rapid revisions.

I am perfectly happy with all of the proposed revisions below.

I think the amended document is ready to progress.

Cheers
Terry

On 28/02/2013, at 4:26 PM, Stephen Kent wrote:

>    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.) 
>    <Specify one or more entities that operate a repository holding certificates,
>    <insert SIDR-designted protocol name here> at <insert URL here>. This repository will 
>    conform to the structure described in [RFC6481].
>    Any subscriber in good standing who holds INRs distributed by this 
> plan to continue/restore operation of your RPKI CA in the event of a disaster.>
>  
> 
> Steve 
> 
> 
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Feb 2013 09:30:09 -0500

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