Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)
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. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)
I guess I should have also said that I support moving this draft down the path towards publication. spt On 3/4/13 6:40 PM, Terry Manderson wrote: 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 On 02/03/2013, at 2:37 AM, Christopher Morrow morrowc.li...@gmail.com wrote: 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 turn...@ieca.com 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)
On Mon, Mar 4, 2013 at 6:56 PM, Sean Turner turn...@ieca.com 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. spt On 3/4/13 6:40 PM, Terry Manderson wrote: 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 On 02/03/2013, at 2:37 AM, Christopher Morrow morrowc.li...@gmail.com wrote: 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 turn...@ieca.com 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)
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 turn...@ieca.com 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)
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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)
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: Terry, Thanks for the feedback. Below are responses to your comments. On 2/27/13 11:48 PM, Terry Manderson wrote: 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.' How about the following revision to the preface: 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.) 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. 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. 3) Nit: Section 1.6 Page 11. There appears to be an extra tab- in the definition if ISP, NIR, and RPKI-signed object. fixed. 4) Section 2.1 via RSYNC. Can that be adjusted to standardised 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 structure described in [RFC6481]. 5) In section 4.1.1, can Any subscriber who holds.., be amended to Any 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 from the template? 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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
