From rv at NIC.DTAG.DE Sun Aug 17 22:16:33 2008 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Sun, 17 Aug 2008 22:16:33 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: Your message of "Thu, 24 Jul 2008 14:13:04 +0200." Message-ID: <7908.1219004193@x37.NIC.DTAG.DE> Dear Filiz, dear fellow task force members, this is my comment to Filiz message of July 24 with an updated draft policy proposal and comments on the concerns I raised in my previous message. I do not see my concerns resolved. If allocation status is not yet well defined for RIPE NCC resolving this has to be taken up as a very important issue. (While it's outside of the scope for discussing this policy proposal questions about activety plan, road map etc. have to be raised to senior management and board.) Defining allocation status and all required rules for status changes certainly raises some challenges; it may take considerable time and effort to do it right - and it MUST be done right. Thus it would be a bad idea to try to quickly "fix" allocation status as a small supporting act within the policy development for introducing RPKI. However sweeping "allocation status" under the rug and only referencing "membership status" as a substitute looks like actually doing exactly such a "quick fix" - in a worse way! BTW also Filiz's proposed language with "grace period" seems to me like being quite unspecific and NOT providing clear rules for NCC staff to act on and for members to clearly understand what they have to expect. Please find below my suggestion for policy elements that could be used to establish clear rules, avoiding to sweep "allocation status" under the rug, but reference what I hope to be clearly defined currently available criteria (i.e. membership) to be used until process and policy to deal with withdrawal of allocations have been properly defined. My suggestion: RIPE NCC member LIRs may request certificates for their PA space as allocated by the RIPE NCC. (+add other types of certificates...) Certificates will be issued with a validity period of NN months (e.g. consider 18 months - that would seem to clearly define a sufficient grace period, but needs to be discussed in comparison to the defined schedule of the NCC business process). Certificates will be revoked (only) when allocation of the resource is returned or withdrawn (withdrawn - under policy/process to be defined properly on separate track!), on request of the resource holder (e.g. to facilitate some kind of transfer), or for handling of compromised security in context with reissuing certificates as needed. Renewal of certificates when membership is confirmed for a new year (by receipt of payment of membership fee). is renewal automatic? (if so, then do it after receipt of payment) or does renewal require explicit request? (if only on request, obviously payment status can be checked) Will renewals be done on request anytime? Further remarks: - Filiz comments that she wants to keep certificates as a SERVICES policy; but in the form under 6. "Address Policy" is listed as the suggested WG; I'd agree with "Services" - first sentence under "10. Policy text" mentions only certificates for PA address space (and "9. summary" similarly); this can be read as defining much more limited service than I was expecting. Please comment/clarify: Existing text remains silent on certificates for AS - is that intentional or do we fix it be explicit mentioning. (AS do NOT look critical or particularly interesting at this time.) A more interesting question is: is the policy considered to cover also provisioning of ROAs? That's actually the application that I consider of highest practical interest - and support of (only?) hosted provisioning of ROAs indeed seems to require specific language (hosted certificates for subdelegations might be another extra item) - I think it would be a good idea to actually mention RPKI and hint at the global context under "6. Summary" Let me also mention that my understanding of requirements for creating a technically and legally correct system there is a need for having Certificate Policy for the RPKI (open proposal: draft-ietf-sidr-cp-03.txt) (global binding agreement!) and for the RIPE NCC as registry running an RPKI CA a Certificate Practices Statement (CPS - draft template see draft-ietf-sidr-cps-irs-03.txt); the later probably is not sufficient to cover hosted operation fully. Best regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From filiz at ripe.net Thu Aug 28 04:06:00 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 28 Aug 2008 04:06:00 +0200 Subject: [ca-tf] Certification Proposal In-Reply-To: <7908.1219004193@x37.NIC.DTAG.DE> References: <7908.1219004193@x37.NIC.DTAG.DE> Message-ID: <01B0849A-0041-46A2-ABCB-4FF611766D3E@ripe.net> Dear all, I am working on this internally at the moment and I will get back to you soon. In the meanwhile if others have opinions on these points please let us know on the list :). Thanks, Filiz On 17 Aug 2008, at 22:16, Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: > Dear Filiz, dear fellow task force members, > > this is my comment to Filiz message of July 24 with an updated > draft policy proposal and comments on the concerns I raised in my > previous message. > > I do not see my concerns resolved. > If allocation status is not yet well defined for RIPE NCC > resolving this has to be taken up as a very important issue. > (While it's outside of the scope for discussing this policy proposal > questions about activety plan, road map etc. have to be raised to > senior management and board.) > Defining allocation status and all required rules for status changes > certainly raises some challenges; it may take considerable time and > effort > to do it right - and it MUST be done right. > Thus it would be a bad idea to try to quickly "fix" allocation status > as a small supporting act within the policy development for > introducing RPKI. However sweeping "allocation status" under the > rug and only > referencing "membership status" as a substitute looks like actually > doing exactly such a "quick fix" - in a worse way! > > BTW also Filiz's proposed language with "grace period" seems to me > like > being quite unspecific and NOT providing clear rules for NCC staff > to act on and for members to clearly understand what they have to > expect. > > Please find below my suggestion for policy elements that could be used > to establish clear rules, avoiding to sweep "allocation status" under > the rug, but reference what I hope to be clearly defined currently > available criteria (i.e. membership) to be used until process and > policy to deal with withdrawal of allocations have been properly > defined. > > My suggestion: > > RIPE NCC member LIRs may request certificates for their PA space > as allocated by the RIPE NCC. (+add other types of certificates...) > > Certificates will be issued with a validity period of NN months > (e.g. consider 18 months - that would seem to clearly define a > sufficient > grace period, but needs to be discussed in comparison to the defined > schedule of the NCC business process). > Certificates will be revoked (only) when allocation of the resource is > returned or withdrawn (withdrawn - under policy/process to be defined > properly on separate track!), on request of the resource holder > (e.g. to facilitate some kind of transfer), or for handling of > compromised security in context with reissuing certificates as needed. > > Renewal of certificates when membership is confirmed for a new year > (by receipt of payment of membership fee). > is renewal automatic? (if so, then do it after receipt of payment) > or does renewal require explicit request? > (if only on request, obviously payment status can be checked) > Will renewals be done on request anytime? > > > Further remarks: > > - Filiz comments that she wants to keep certificates as a SERVICES > policy; > but in the form under 6. "Address Policy" is listed as the > suggested WG; > I'd agree with "Services" > > - first sentence under "10. Policy text" mentions only certificates > for PA address space (and "9. summary" similarly); this can be read as > defining much more limited service than I was expecting. > Please comment/clarify: > Existing text remains silent on certificates for AS - is that > intentional or do we fix it be explicit mentioning. > (AS do NOT look critical or particularly interesting at this time.) > A more interesting question is: > is the policy considered to cover also provisioning of ROAs? > That's actually the application that I consider of highest > practical interest - and support of (only?) hosted provisioning > of ROAs indeed seems to require specific language > (hosted certificates for subdelegations might be another > extra item) > > - I think it would be a good idea to actually mention RPKI and hint at > the global context under "6. Summary" > > Let me also mention that my understanding of requirements for creating > a technically and legally correct system there is a need for having > Certificate Policy for the RPKI (open proposal: draft-ietf-sidr- > cp-03.txt) > (global binding agreement!) and for the RIPE NCC as registry running > an RPKI CA a Certificate Practices Statement (CPS - draft template see > draft-ietf-sidr-cps-irs-03.txt); the later probably is not sufficient > to cover hosted operation fully. > > Best regards, > Ruediger > > > Ruediger Volk > > Deutsche Telekom AG -- Internet Backbone Engineering > > E-Mail: rv at NIC.DTAG.DE