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
