From gert at Space.Net Fri Mar 19 11:56:15 2010 From: gert at Space.Net (Gert Doering) Date: Fri, 19 Mar 2010 11:56:15 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? Message-ID: <20100319105615.GA8479@Space.Net> Hi CA-TF, it has been a bit quiet on this list since December, and I'm wondering what happened regarding 2008-08 ("Initial Certification Policy for PA Space Holders"). It's still sitting in the APWG open policy proposals queue, and I'd like to see this go forward... Feedback has been given by the community at the last meeting, so I think we (well, "you", I'm just steering this from the WG chair side) can do something here. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From andrew at ripe.net Fri Mar 19 15:04:35 2010 From: andrew at ripe.net (Andrew de la Haye) Date: Fri, 19 Mar 2010 15:04:35 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <20100319105615.GA8479@Space.Net> References: <20100319105615.GA8479@Space.Net> Message-ID: Hi Gert, since the last RIPE meeting where we met with the CA-TF and with the community, we have been very active on several levels. - Technical implementation and production readiness plans (aim: production ready January 2011) - Drafting Certification Practice Statement (CPS) and aligning Certification Policy (CP) with other RIRs (I'll be able to give you a date of delivery of first draft after the IETF of next week) - Legal impact assessment (draft from lawyers received) - Analysing of other documentation (mainly IETF standards related) - Drafting roll-out plan which consists of: --- external audit (to be planned) --- getting feedback from a wider audience (including short survey) --- analyse strength and weaknesses (ongoing) --- implementation plan (ongoing) --- communication strategy (alignment with other RIRs) --- development of toolset according to feedback from membership (to be started) We have now a dedicated resource on the roll-out plan, which is Alex Band (our TS rep. who delivered the RIPE 59 Cert update). On the topic of RIPE Policy I have made the following observation: During RIPE 59, there were presentations from Nigel and Stephen Kent. Stephen focused on the technical aspects and capabilities of a certification system, following the feedback from the previous meeting and discussions. Most of the discussion concerning Certification revolves around technical details and implementation issues (which are being covered by the CPS). Next to this, the target audience needing to adopt Certification, is more concerned with the is benefits of the system to their organisation. It seems there is difficulty within community to agree on a broader policy document before seeing practical issues on a less formal document. Following this how would the CA-TF feel about withdrawing the current policy proposal (2008-08)? We like to invite the CA_TF for a more elaborate update and exchange of ideas at the next RIPE meeting in Prague. The invitation will be send out soon by Alex Band. If you have any questions, please send me your thoughts. Regards, Andrew On Mar 19, 2010, at 11:56 AM, Gert Doering wrote: > Hi CA-TF, > > it has been a bit quiet on this list since December, and I'm wondering what > happened regarding 2008-08 ("Initial Certification Policy for PA Space > Holders"). > > It's still sitting in the APWG open policy proposals queue, and I'd like > to see this go forward... > > Feedback has been given by the community at the last meeting, so I think > we (well, "you", I'm just steering this from the WG chair side) can do > something here. > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 150584 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1727 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100319/8b1db563/attachment.bin From nigel.titley at uk.easynet.net Mon Mar 22 12:32:02 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 22 Mar 2010 11:32:02 +0000 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: References: <20100319105615.GA8479@Space.Net> Message-ID: <1269257522.26268.75.camel@ntitley-laptop> On Fri, 2010-03-19 at 15:04 +0100, Andrew de la Haye wrote: > Hi Gert, > > since the last RIPE meeting where we met with the CA-TF and with the community, we have been very active on several levels. > - Technical implementation and production readiness plans (aim: production ready January 2011) > - Drafting Certification Practice Statement (CPS) and aligning Certification Policy (CP) with other RIRs (I'll be able to give you a date of delivery of first draft after the IETF of next week) > - Legal impact assessment (draft from lawyers received) > - Analysing of other documentation (mainly IETF standards related) > - Drafting roll-out plan which consists of: > --- external audit (to be planned) > --- getting feedback from a wider audience (including short survey) > --- analyse strength and weaknesses (ongoing) > --- implementation plan (ongoing) > --- communication strategy (alignment with other RIRs) > --- development of toolset according to feedback from membership (to be started) > We have now a dedicated resource on the roll-out plan, which is Alex Band (our TS rep. who delivered the RIPE 59 Cert update). > > On the topic of RIPE Policy I have made the following observation: > > During RIPE 59, there were presentations from Nigel and Stephen Kent. Stephen focused on the technical aspects and capabilities of a certification system, following the feedback from the previous meeting and discussions. > > Most of the discussion concerning Certification revolves around technical details and implementation issues (which are being covered by the CPS). Next to this, the target audience needing to adopt Certification, is more concerned with the is benefits of the system to their organisation. > > It seems there is difficulty within community to agree on a broader policy document before seeing practical issues on a less formal document. Following this how would the CA-TF feel about withdrawing the current policy proposal (2008-08)? Well, I don't see any consensus for the policy proposal as originally proposed and I'm happy to withdraw it and just continue with the technical implementation, but this begs the question of how we implement certification from a business perspective. Do we just offer it as a service that any RIPE NCC member can avail themselves of? How long will certificates last? Do we with withdraw them when a member leaves? All the questions that came up during the policy debate still need answering. Nigel From dol at cryptocom.ru Mon Mar 22 13:13:00 2010 From: dol at cryptocom.ru (Basil Dolmatov) Date: Mon, 22 Mar 2010 15:13:00 +0300 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1269257522.26268.75.camel@ntitley-laptop> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> Message-ID: <4BA75ECC.1070404@cryptocom.ru> Nigel Titley ?????: > > Well, I don't see any consensus for the policy proposal as originally > proposed and I'm happy to withdraw it and just continue with the > technical implementation, but this begs the question of how we implement > certification from a business perspective. Do we just offer it as a > service that any RIPE NCC member can avail themselves of? How long will > certificates last? Do we with withdraw them when a member leaves? All How the keys are handled, where it is stored and how, how rollover is performed, what are the conflict resolution procedures and so on, so on, so on. All of these are NOT the technical questions, they are BUSINESS ones. > the questions that came up during the policy debate still need > answering. Moreover, maybe the movement in different direction will be more feasible (cf. Halam-Baker messages in IETF discussion list) or some hybrid solution. dol@ > > Nigel > From gert at space.net Mon Mar 22 16:45:56 2010 From: gert at space.net (Gert Doering) Date: Mon, 22 Mar 2010 16:45:56 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1269257522.26268.75.camel@ntitley-laptop> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> Message-ID: <20100322154556.GS69383@Space.Net> Hi, On Mon, Mar 22, 2010 at 11:32:02AM +0000, Nigel Titley wrote: > Well, I don't see any consensus for the policy proposal as originally > proposed Definitely not... > and I'm happy to withdraw it ... but I don't think that this should be the right way. I'd go for "v2.0" of the proposal that incorporates clear words to address the issues voiced by the community. > and just continue with the > technical implementation, but this begs the question of how we implement > certification from a business perspective. Do we just offer it as a > service that any RIPE NCC member can avail themselves of? How long will > certificates last? Do we with withdraw them when a member leaves? All > the questions that came up during the policy debate still need > answering. That's why I think a "v2.0" of the proposal with some answers to that makes sense. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100322/446fb009/attachment.bin From nigel.titley at uk.easynet.net Tue Mar 23 13:18:00 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Tue, 23 Mar 2010 12:18:00 +0000 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <20100322154556.GS69383@Space.Net> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> Message-ID: <1269346680.3914.10.camel@ntitley-laptop> On Mon, 2010-03-22 at 16:45 +0100, Gert Doering wrote: > > That's why I think a "v2.0" of the proposal with some answers to that > makes sense. Yes, I'm beginning to agree with you. Merely dropping the proposal gives the impression that the RIPE NCC is just going to steam roller ahead regardless of what the community thinks or wants. And this is something that we want to avoid at all costs. Nigel From andrew at ripe.net Wed Mar 24 17:14:55 2010 From: andrew at ripe.net (Andrew de la Haye) Date: Wed, 24 Mar 2010 17:14:55 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1269346680.3914.10.camel@ntitley-laptop> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> Message-ID: <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> Hi Gert, Nigel, I appreciate your comments. Below some food for thoughts. It is of course without question that the Certification system is based on Community wishes and looks after their interests, like robust Registry data and secure and stable routing on the Internet. One of the reasons that the CEOs of the five RIRs have commmitted to having a production system ready by the 1st of January 2011, is because Certification is merely an additional opt-in member service, that ties in to what is already available. It is another representation of the allocation status which follows the policies we already have, along with the membership status (this is also supported in the first draft of the legal assessment). This means the questions Nigel raises could in fact already be answered: > Do we just offer it as a service that any RIPE NCC member can avail themselves of? Precisely, the LIR is free to choose to go into the LIR Portal and get a Certificate for their Internet resources. > How long will certificates last? They expire after one year and will be automatically rolled over and renewed, for as long as you remain a member. Just like our current business process for allocations, again in this process the certificates just follow their allocations. > Do we with withdraw them when a member leaves? Reclaiming address space after an LIR ceases to be a member is in line with the Community wishes, and with the policies and Resource Lifecycle Management we are committed to. Since the Certificate is tied to address space, it would automatically mean the certificate gets invalid (after a grace period) once they stop being a member. This is analogous to the RIPE Database entries being removed, and the reverse DNS service being stopped. Once the address space has been reclaimed and reissued to another member, they would be able to get a certificate for it. Obviously we are concerned about the impression that we are pushing this forward. I would like to reiterate a point out of my previous message: we have realized people are more concerned with the benefits of the system to their organisation than with aspects like the time the certificate lasts. So instead of waiting for someone to voice their opinion as we have done with 2008-08 with little result, we're using targeted messaging, as well as a survey and training courses to actively gather feedback. Based on the results, we will do a thorough analysis and make a decision that is in the best interest of our Community. Regards, Andrew On 22 Mar 2010, at 16:45, Gert Doering wrote: > Hi, > > On Mon, Mar 22, 2010 at 11:32:02AM +0000, Nigel Titley wrote: >> Well, I don't see any consensus for the policy proposal as originally >> proposed > > Definitely not... > >> and I'm happy to withdraw it > > ... but I don't think that this should be the right way. I'd go for > "v2.0" of the proposal that incorporates clear words to address the > issues voiced by the community. > >> and just continue with the >> technical implementation, but this begs the question of how we implement >> certification from a business perspective. Do we just offer it as a >> service that any RIPE NCC member can avail themselves of? How long will >> certificates last? Do we with withdraw them when a member leaves? All >> the questions that came up during the policy debate still need >> answering. > > That's why I think a "v2.0" of the proposal with some answers to that > makes sense. On 23 Mar 2010, at 13:18, Nigel Titley wrote: > On Mon, 2010-03-22 at 16:45 +0100, Gert Doering wrote: > >> >> That's why I think a "v2.0" of the proposal with some answers to that >> makes sense. > > Yes, I'm beginning to agree with you. Merely dropping the proposal gives > the impression that the RIPE NCC is just going to steam roller ahead > regardless of what the community thinks or wants. And this is something > that we want to avoid at all costs. > > Nigel > On Mar 23, 2010, at 1:18 PM, Nigel Titley wrote: > On Mon, 2010-03-22 at 16:45 +0100, Gert Doering wrote: > >> >> That's why I think a "v2.0" of the proposal with some answers to that >> makes sense. > > Yes, I'm beginning to agree with you. Merely dropping the proposal gives > the impression that the RIPE NCC is just going to steam roller ahead > regardless of what the community thinks or wants. And this is something > that we want to avoid at all costs. > > Nigel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1727 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100324/b2b10e2a/attachment.bin From nigel.titley at uk.easynet.net Wed Mar 24 18:05:50 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Wed, 24 Mar 2010 17:05:50 +0000 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> Message-ID: <1269450350.31857.38.camel@ntitley-laptop> On Wed, 2010-03-24 at 17:14 +0100, Andrew de la Haye wrote: > Hi Gert, Nigel, > > I appreciate your comments. Below some food for thoughts. > > It is of course without question that the Certification system is based on Community wishes and looks after their interests, like robust Registry data and secure and stable routing on the Internet. But the problem is that the community is not happy with the system as proposed. > One of the reasons that the CEOs of the five RIRs have commmitted to having a production system ready by the 1st of January 2011, is because Certification is merely an additional opt-in member service, that ties in to what is already available. It is another representation of the allocation status which follows the policies we already have, along with the membership status (this is also supported in the first draft of the legal assessment). This is without dispute... however the details of the system are what are causing the problem. Certification is generally seen as A Good Thing but there are issues with the system as proposed. > This means the questions Nigel raises could in fact already be answered: > > > Do we just offer it as a service that any RIPE NCC member can avail themselves of? > > Precisely, the LIR is free to choose to go into the LIR Portal and get a Certificate for their Internet resources. This is fine > > How long will certificates last? > > They expire after one year and will be automatically rolled over and renewed, for as long as you remain a member. Just like our current business process for allocations, again in this process the certificates just follow their allocations. Now, this was one of the sticking points. The community wanted a system with much longer expiry periods. Personally I see no reason not to have longer expiry periods. The community suggested 10 years. I would suggest a compromise of 5 years. > > Do we with withdraw them when a member leaves? > > Reclaiming address space after an LIR ceases to be a member is in line with the Community wishes, and with the policies and Resource Lifecycle Management we are committed to. Since the Certificate is tied to address space, it would automatically mean the certificate gets invalid (after a grace period) once they stop being a member. This is analogous to the RIPE Database entries being removed, and the reverse DNS service being stopped. Once the address space has been reclaimed and reissued to another member, they would be able to get a certificate for it. The issue was not with reclaiming address space per se. Everyone agrees that one address space is truly reclaimed, the certificates should be revoked. However, I see no reason why address reclamation should not be linked with certificate revocation rather than just letting the certificates expire. I know this is more work for the RIPE NCC but I feel that it may be worth it for the sake of the extra degree of comfort it provides that space may not be withdrawn arbitrarily (however unlikely this may be). So what I would propose is the following: 1. Address space is allocated, certificate is issued, expiry period 5 years 2. Each year, membership is renewed and certificates are re-issued with a further 5 year expiry. 3. If address space is reclaimed (for whatever reason), the certificate is revoked. Now I know this is less neat than the proposed method, but it addresses the major perceived problem of the community; that while an LIR is disputing membership payments (or they get lost, or whatever) then the certificate expires and the prefix is no longer routable (once we have SIDR). We have another problem, that some administrations see the ability of the RIRs to withdraw a certificate (and hence shut off prefixes from being routed) as an infringement of national sovereignty. There isn't a solution to this although it may be ameliorated by the RIPE NCC making a public statement that it will only ever withdraw a certificate as a result of a Dutch court order, and then only after having exhausted all legal avenues of dispute. > Obviously we are concerned about the impression that we are pushing this forward. I would like to reiterate a point out of my previous message: we have realized people are more concerned with the benefits of the system to their organisation than with aspects like the time the certificate lasts. So instead of waiting for someone to voice their opinion as we have done with 2008-08 with little result, we're using targeted messaging, as well as a survey and training courses to actively gather feedback. Based on the results, we will do a thorough analysis and make a decision that is in the best interest of our Community. I strongly disagree with you. The RIPE NCC *cannot* "make a decision that is in the best interest of our Community" without the community agreeing. To do otherwise is to undermine the entire PDP. We cannot allow that to happen. Nigel > Regards, > Andrew > > > On 22 Mar 2010, at 16:45, Gert Doering wrote: > > > Hi, > > > > On Mon, Mar 22, 2010 at 11:32:02AM +0000, Nigel Titley wrote: > >> Well, I don't see any consensus for the policy proposal as originally > >> proposed > > > > Definitely not... > > > >> and I'm happy to withdraw it > > > > ... but I don't think that this should be the right way. I'd go for > > "v2.0" of the proposal that incorporates clear words to address the > > issues voiced by the community. > > > >> and just continue with the > >> technical implementation, but this begs the question of how we implement > >> certification from a business perspective. Do we just offer it as a > >> service that any RIPE NCC member can avail themselves of? How long will > >> certificates last? Do we with withdraw them when a member leaves? All > >> the questions that came up during the policy debate still need > >> answering. > > > > That's why I think a "v2.0" of the proposal with some answers to that > > makes sense. > > On 23 Mar 2010, at 13:18, Nigel Titley wrote: > > > On Mon, 2010-03-22 at 16:45 +0100, Gert Doering wrote: > > > >> > >> That's why I think a "v2.0" of the proposal with some answers to that > >> makes sense. > > > > Yes, I'm beginning to agree with you. Merely dropping the proposal gives > > the impression that the RIPE NCC is just going to steam roller ahead > > regardless of what the community thinks or wants. And this is something > > that we want to avoid at all costs. > > > > Nigel > > > On Mar 23, 2010, at 1:18 PM, Nigel Titley wrote: > > > On Mon, 2010-03-22 at 16:45 +0100, Gert Doering wrote: > > > >> > >> That's why I think a "v2.0" of the proposal with some answers to that > >> makes sense. > > > > Yes, I'm beginning to agree with you. Merely dropping the proposal gives > > the impression that the RIPE NCC is just going to steam roller ahead > > regardless of what the community thinks or wants. And this is something > > that we want to avoid at all costs. > > > > Nigel > > > > > From gert at space.net Thu Mar 25 14:45:27 2010 From: gert at space.net (Gert Doering) Date: Thu, 25 Mar 2010 14:45:27 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1269450350.31857.38.camel@ntitley-laptop> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> Message-ID: <20100325134527.GG69383@Space.Net> Hi Nigel, Andrew, & co :) On Wed, Mar 24, 2010 at 05:05:50PM +0000, Nigel Titley wrote: > On Wed, 2010-03-24 at 17:14 +0100, Andrew de la Haye wrote: > > I appreciate your comments. Below some food for thoughts. > > > > It is of course without question that the Certification system is based > > on Community wishes and looks after their interests, like robust > > Registry data and secure and stable routing on the Internet. > > But the problem is that the community is not happy with the system as > proposed. [..] > This is without dispute... however the details of the system are what > are causing the problem. Certification is generally seen as A Good Thing > but there are issues with the system as proposed. Yes, indeed. But I think we have seen some guidance, and Nigel's proposed plan should (hopefully) make the community go along. [..] > Now, this was one of the sticking points. The community wanted a system > with much longer expiry periods. Personally I see no reason not to have > longer expiry periods. The community suggested 10 years. I would suggest > a compromise of 5 years. [..] > > So what I would propose is the following: > > 1. Address space is allocated, certificate is issued, expiry period 5 > years > > 2. Each year, membership is renewed and certificates are re-issued with > a further 5 year expiry. > > 3. If address space is reclaimed (for whatever reason), the certificate > is revoked. I think that this should address most of the concerns voiced (see below for the last one). [..] > We have another problem, that some administrations see the ability of > the RIRs to withdraw a certificate (and hence shut off prefixes from > being routed) as an infringement of national sovereignty. There isn't a > solution to this although it may be ameliorated by the RIPE NCC making a > public statement that it will only ever withdraw a certificate as a > result of a Dutch court order, and then only after having exhausted all > legal avenues of dispute. We had a nice technical trick presented: if the revocation certificate contains the *reason* for the revocation (non-payment, governmental mandate, ...), and the client software can be configured to ignore certain types of revocations, and keep the certificate it has in its cache, then the ISPs can decide to just ignore such measures by the administration. ... thus making it useless, and stopping it cold ("you could do this but since it won't have an effect, you could as well just let it be"). [..] > I strongly disagree with you. The RIPE NCC *cannot* "make a decision > that is in the best interest of our Community" without the community > agreeing. To do otherwise is to undermine the entire PDP. We cannot > allow that to happen. Fully agree with Nigel here. This is a touchy issue, as it changes the way "The Internet" works, and the NCC must avoid being seen as "we decide what is good for you". People are already assuming a conspiracy behind half of the policy things we do - even if they are fully in the open (this is a bit irrational, but "real" people *are* irrational at times). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100325/de59a36a/attachment.bin From robert at ripe.net Thu Mar 25 17:21:52 2010 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 25 Mar 2010 09:21:52 -0700 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1269450350.31857.38.camel@ntitley-laptop> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> Message-ID: <4BAB8DA0.3070101@ripe.net> Hi, (I'm only addressing the technicalities here.) On 2010.03.24. 10:05, Nigel Titley wrote: > So what I would propose is the following: > > 1. Address space is allocated, certificate is issued, expiry period 5 > years > > 2. Each year, membership is renewed and certificates are re-issued with > a further 5 year expiry. > > 3. If address space is reclaimed (for whatever reason), the certificate > is revoked. I believe that this is a viable way of doing it. I'd add that for key lifetime reasons, the members SHOULD introduce new keys every 1-2 years. > Now I know this is less neat than the proposed method, but it addresses > the major perceived problem of the community; that while an LIR is > disputing membership payments (or they get lost, or whatever) then the > certificate expires and the prefix is no longer routable (once we have > SIDR). > > We have another problem, that some administrations see the ability of > the RIRs to withdraw a certificate (and hence shut off prefixes from > being routed) as an infringement of national sovereignty. There isn't a > solution to this although it may be ameliorated by the RIPE NCC making a > public statement that it will only ever withdraw a certificate as a > result of a Dutch court order, and then only after having exhausted all > legal avenues of dispute. I must observe that none of the secure routing drafts say "you must reject an invalid signed route" -- they only affect the preferences in best path selection. That is a big difference, as revoking a certificate does _not_ tell anyone they should drop that announcement, merely that it's not as attractive as others may be. And even that only applies to direct path selection in the routers themselves, they have got nothing to do with filter constructions, where the choice is 100% up to the individual ISPs. Robert From nigel.titley at uk.easynet.net Fri Mar 26 17:30:09 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Fri, 26 Mar 2010 16:30:09 +0000 Subject: [apwg-chairs] Re: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> <4BAB8DA0.3070101@ripe.net> Message-ID: <1269621009.11125.15.camel@ntitley-laptop> On Fri, 2010-03-26 at 11:15 +0100, Sander Steffann wrote: > Hi, > > > I must observe that none of the secure routing drafts say "you must reject an invalid signed route" -- they only affect the preferences in best path selection. That is a big difference, as revoking a certificate does _not_ tell anyone they should drop that announcement, merely that it's not as attractive as others may be. > > > > And even that only applies to direct path selection in the routers themselves, they have got nothing to do with filter constructions, where the choice is 100% up to the individual ISPs. > > This is what the community needs to hear. If everybody understands this there will be a lot less resistance. I think that this has always been understood by anyone that actually takes the trouble. However, for those ISPs who *don't* understand, rather like those people who apply RBL filters without understanding them, there is always the good chance that unsigned/invalidly signed prefixes will be dropped. However, I think if we take the action to generate BCP documents to aid the, err..., more technically challenged ISPs out there, as and when the secure routing stuff starts to appear then we will sooth fears greatly, as Sander says. Nigel From robert at ripe.net Fri Mar 26 19:11:59 2010 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 26 Mar 2010 11:11:59 -0700 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <20100325134527.GG69383@Space.Net> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> <20100325134527.GG69383@Space.Net> Message-ID: <4BACF8EF.1090005@ripe.net> Hi, (Again, I'm only addressing the technicalities here.) On 2010.03.25. 6:45, Gert Doering wrote: >> We have another problem, that some administrations see the ability of >> the RIRs to withdraw a certificate (and hence shut off prefixes from >> being routed) as an infringement of national sovereignty. There isn't a >> solution to this although it may be ameliorated by the RIPE NCC making a >> public statement that it will only ever withdraw a certificate as a >> result of a Dutch court order, and then only after having exhausted all >> legal avenues of dispute. > > We had a nice technical trick presented: if the revocation certificate > contains the *reason* for the revocation (non-payment, governmental > mandate, ...), and the client software can be configured to ignore > certain types of revocations, and keep the certificate it has in its > cache, then the ISPs can decide to just ignore such measures by the > administration. > > ... thus making it useless, and stopping it cold ("you could do this but > since it won't have an effect, you could as well just let it be"). Data point: the applicable standard (RFC 5280, section 5.3.1) does not support the above revocation reasons. Robert From gert at space.net Fri Mar 26 22:57:42 2010 From: gert at space.net (Gert Doering) Date: Fri, 26 Mar 2010 22:57:42 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <4BACF8EF.1090005@ripe.net> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> <20100325134527.GG69383@Space.Net> <4BACF8EF.1090005@ripe.net> Message-ID: <20100326215742.GY69383@Space.Net> hi, On Fri, Mar 26, 2010 at 11:11:59AM -0700, Robert Kisteleki wrote: > Data point: the applicable standard (RFC 5280, section 5.3.1) does not > support the above revocation reasons. Good argument. Since I'm not the crypto expert, I can only relay what has been proposed at the last APWG meeting... (and that seemed to make sense). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From andrew at ripe.net Wed Mar 31 10:37:43 2010 From: andrew at ripe.net (Andrew de la Haye) Date: Wed, 31 Mar 2010 10:37:43 +0200 Subject: [ca-tf] Certification-Policy Proposal - next steps? Message-ID: Dear Certification Task Force members, I am very happy that the discussion around this topic has come to life like this. I think we all agree that the value of Resource Certification lies in the fact that a certificate represents the truth. We should never lose sight of that, or it will undermine the credibility of the system, and with it the viability. With this in mind, I would like to make a couple of points, which I hope can lead to a proposal made by the CA-TF. 1. Resource Certification is inextricably tied to the business relationship with the LIR First, I would like there to be absolutely no misunderstandings about our membership process: When an organisation wants to become an LIR, we first diligently check their identity and company registration papers. This forms the foundation to all services we offer to them: Internet Resource allocations, Billing, LIR Portal access, RIPE Database entries, Reverse DNS Delegations, etc. So only for as long as we have business relationship with the LIR, we can make attestations about their identity, allocation status and everything else. When the registry closes because of bankruptcy, non-payment (http://www.ripe.net/info/faq/membership/billing.html#6) or any other reason, our business relationship ends. We will reclaim the Internet Resources (applying Lifecycle Management), remove the RIPE Database entries and stop the Reverse DNS Delegation. Reclaimed resources will be reissued to another LIR. When there is a dispute, we have an Arbitration Process: http://www.ripe.net/membership/arbitration.html Resource Certification fits exactly into this model. We can only sign and renew certificates if we have a business relationship with a member. The PKI reason for this is that only then we can be sure that we are dealing with the correct people. Since Certification is just a different representation of our allocation data, it must follow the same process. If the business relationship is discontinued, having certificates that do not reflect this, will cause a deterioration of the value of the system. Not aligning with the current business process will increase complexity, understandability of what is the state of the business relationship and will deteriorate the trust in the system. If the fear for disputes is the main driver for this issue, then we should refer to the Arbitration Process: in case of dispute we will not reclaim resources and allow the holder to create a new valid certificate until the dispute is being solved. 2. Resource Certification is an additional, opt-in member service Network operators are free to make route filtering choices they want. They can choose to not filter at all, manually filter based on local policy, or filter based on Whois Database and Internet Routing Registry data. Resource Certification intends to offer more robustness, improved data quality, and easier validation. It will provide an additional piece of information a network operator is free to base decisions on. We will offer a tool that checks certificates and ROAs and only indicates what the status is. In its current form, Certification will be offered in a hosted solution through the LIR Portal, where the user can manage ROA specifications. The system will take care of all the crypto operations like certificate requests and renewals, re-keys and make sure corresponding ROA objects are generated and published. The user only has access to this system for as long as they are a member, as explained in point 1. 3. Power, control and legal implications of the implementation of Certification The possibilities for law enforcement agencies to take measures against the Resource Certification system run by the RIPE NCC are very limited, if existent at all. Under Dutch law, the process of Certification, as well as Resource Certificates themselves do not qualify as goods that are capable of being confiscated. If in the extremely unlikely case this this were to happen anyway, then it will prove utterly ineffective. This is because a revoked Certificate or ROA has the same status as a non-existent one, since this is an opt-in service network operators are free to base decisions on, as explained in point 2. Simply put, Resource Certification can drive a preference. The existence of a Certificate and ROA is a positive message, the absence is not a negative one. The revoked status is not a negative statement either, for as long as a new certificate for that resource has not been issued. These statements are supported by IETF documentation, the current draft can be found here: http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-04.txt Section 3.1 'Policy Control' says: "It MUST be possible to enable or disable the validation step as defined in Section 3 through configuration. The default SHOULD be for the validation step to be enabled. An implementation MAY also support disabling validation for a subset of prefixes or for routes received from a particular EBGP peer....." This confirms the idea that having a valid ROA for a given announcement is a plus, but there *must* be ways for operators to override or even disable this. It may interest the CA-TF that both Cisco and Juniper contribute to this draft and will most likely follow this document in the implementations that they will provide for their routers in the future. 4. Inter-RIR considerations I met with the other RIRs at the IETF. Below in the table is my interpretation on how they look at Certification on three main topics. I hope this offers some additional perspective: ARIN APNIC LACNIC AFRINIC Opt-in vs. Push Opt-in Opt-in Opt-in Opt-in Community vs. member service Member service, no policy needed other than the CPS Member service, no policy Member service, tend to no policy due to lack of community input Member service, policy to be decided Cert validity Membership aligned Membership aligned Tend to membership aligned Membership aligned Closing thoughts and conclusion A lot of the discussion around Resource Certification has revolved around technical implementation details. However, most of the proposals with a technical nature seem to have been made in order to resolve a concern that is actually policy or business related. I hope this message offers some perspective, and outlines how we can implement Resource Certification ensuring the best possible robustness and security, while keeping the system open, transparent and easy to understand and use for the Community. With this in mind, I believe it will be very beneficial for the proposal that the CA-TF will come up with, to contain the following: a. The way Resource Certification will tie into our current business processes b. The fact that Resource Certification is an additional, opt-in member service c. That in case of a dispute, we have an Arbitration Process in place. During the procedure, we will not reclaim resources, and Certification will remain available to the member. d. How Resource Certification is aimed at aiding the network operator in making routing decisions, and does not enforce anything, also when Secure BGP becomes a reality e. The possibilities for law enforcement agencies to take measures against the Resource Certification are very limited, if existent at all. f. The fact that we will have a Certification Practice Statement that reflects this Naturally, the RIPE NCC is more than happy to support drafting a proposal. Regards, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100331/0f72746d/attachment.html From sander at steffann.nl Wed Mar 24 21:48:54 2010 From: sander at steffann.nl (Sander Steffann) Date: Wed, 24 Mar 2010 21:48:54 +0100 Subject: [apwg-chairs] Re: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1269450350.31857.38.camel@ntitley-laptop> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> Message-ID: Hi, >> Obviously we are concerned about the impression that we are pushing this forward. I would like to reiterate a point out of my previous message: we have realized people are more concerned with the benefits of the system to their organisation than with aspects like the time the certificate lasts. So instead of waiting for someone to voice their opinion as we have done with 2008-08 with little result, we're using targeted messaging, as well as a survey and training courses to actively gather feedback. Based on the results, we will do a thorough analysis and make a decision that is in the best interest of our Community. > > I strongly disagree with you. The RIPE NCC *cannot* "make a decision > that is in the best interest of our Community" without the community > agreeing. To do otherwise is to undermine the entire PDP. We cannot > allow that to happen. I fully agree with Nigel here. Certification is linked to address policy, and community members have expressed concern about this. If the NCC goes ahead with an implementation without following the PDP then the NCC will be acting against the explicit wishes of the community. It will be a very bad precedent. The whole bottom-up process will be lost. - Sander From sander at steffann.nl Fri Mar 26 11:15:08 2010 From: sander at steffann.nl (Sander Steffann) Date: Fri, 26 Mar 2010 11:15:08 +0100 Subject: [apwg-chairs] Re: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <4BAB8DA0.3070101@ripe.net> References: <20100319105615.GA8479@Space.Net> <1269257522.26268.75.camel@ntitley-laptop> <20100322154556.GS69383@Space.Net> <1269346680.3914.10.camel@ntitley-laptop> <22D69723-3996-412C-8742-D9F272D15D1C@ripe.net> <1269450350.31857.38.camel@ntitley-laptop> <4BAB8DA0.3070101@ripe.net> Message-ID: Hi, > I must observe that none of the secure routing drafts say "you must reject an invalid signed route" -- they only affect the preferences in best path selection. That is a big difference, as revoking a certificate does _not_ tell anyone they should drop that announcement, merely that it's not as attractive as others may be. > > And even that only applies to direct path selection in the routers themselves, they have got nothing to do with filter constructions, where the choice is 100% up to the individual ISPs. This is what the community needs to hear. If everybody understands this there will be a lot less resistance. Sander