From nigel.titley at uk.easynet.net Mon May 3 14:58:03 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 03 May 2010 13:58:03 +0100 Subject: [ca-tf] Policy proposal Message-ID: <1272891483.6612.147.camel@ntitley-laptop> Folks Following this morning's discussion, here is my proposal for the slide set. I think it roughly summarises the discussion. It may look a bit bald, but the supporting patter should take the edge off. Comments and brickbats please. I know it is less than ideal, but we need to get *something* agreed out there. Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: 2008-08.pdf Type: application/pdf Size: 138809 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100503/d87cd1fd/attachment.pdf From randy at psg.com Mon May 3 15:07:47 2010 From: randy at psg.com (Randy Bush) Date: Mon, 03 May 2010 15:07:47 +0200 Subject: [ca-tf] Re: Policy proposal In-Reply-To: <1272891483.6612.147.camel@ntitley-laptop> References: <1272891483.6612.147.camel@ntitley-laptop> Message-ID: s/Competance/Competence/ Way Forward: decouple immediate (we wish) deployment from coming to community convergence on forward policy cool! randy From robert at ripe.net Mon May 3 15:19:41 2010 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 03 May 2010 15:19:41 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <1272891483.6612.147.camel@ntitley-laptop> References: <1272891483.6612.147.camel@ntitley-laptop> Message-ID: <4BDECD6D.8030101@ripe.net> On 2010.05.03. 14:58, Nigel Titley wrote: > Folks > > Following this morning's discussion, here is my proposal for the slide > set. I think it roughly summarises the discussion. It may look a bit > bald, but the supporting patter should take the edge off. > > Comments and brickbats please. I know it is less than ideal, but we need > to get *something* agreed out there. > > Nigel > On slide 7: I think that the 3-5 year validity and the "reissue annually" are mutually exclusive. The reason why you want to have 3-5 years in the first place is to avoid the issues arising from not re-issuing. In other word, it doesn't make sense to re-issue if the previous certificate is still valid. Regards, Robert From gert at space.net Mon May 3 15:22:50 2010 From: gert at space.net (Gert Doering) Date: Mon, 3 May 2010 15:22:50 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <1272891483.6612.147.camel@ntitley-laptop> References: <1272891483.6612.147.camel@ntitley-laptop> Message-ID: <20100503132250.GE60850@Space.Net> Hi, On Mon, May 03, 2010 at 01:58:03PM +0100, Nigel Titley wrote: > Following this morning's discussion, here is my proposal for the slide > set. I think it roughly summarises the discussion. It may look a bit > bald, but the supporting patter should take the edge off. > > Comments and brickbats please. I know it is less than ideal, but we need > to get *something* agreed out there. I like it. Clearly explain to the community why we're stuck, and what the potential ways forward are. Then carefully prevent them from hanging themselves... Gert Doering -- 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 gert at space.net Mon May 3 15:25:35 2010 From: gert at space.net (Gert Doering) Date: Mon, 3 May 2010 15:25:35 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <4BDECD6D.8030101@ripe.net> References: <1272891483.6612.147.camel@ntitley-laptop> <4BDECD6D.8030101@ripe.net> Message-ID: <20100503132535.GF60850@Space.Net> Hi, On Mon, May 03, 2010 at 03:19:41PM +0200, Robert Kisteleki wrote: > On slide 7: I think that the 3-5 year validity and the "reissue annually" > are mutually exclusive. The reason why you want to have 3-5 years in the > first place is to avoid the issues arising from not re-issuing. In other > word, it doesn't make sense to re-issue if the previous certificate is still > valid. Mabye "re-issue" is not the correct crypto word here. I know that in SSL web certificates, it's best current practice to issue "new" certificates a few weeks before the "old" certificate runs out (avoiding the term re-issue) - to give people a bit of slack to upgrade their end, not having a flag day. I think that's the point: not having a flag day where the old cert runs out and a "somewhat lazy" LIR does not have time to install the new one in time. So how to phrase that correct in terms of X.509 crypto? Gert Doering -- 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 gert at space.net Mon May 3 15:37:53 2010 From: gert at space.net (Gert Doering) Date: Mon, 3 May 2010 15:37:53 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: References: <1272891483.6612.147.camel@ntitley-laptop> <20100503132250.GE60850@Space.Net> Message-ID: <20100503133753.GI60850@Space.Net> Hi, On Mon, May 03, 2010 at 03:29:35PM +0200, Randy Bush wrote: > > I like it. Clearly explain to the community why we're stuck, and what > > the potential ways forward are. Then carefully prevent them from hanging > > themselves... > ourselves Thanks for the reminder. Yes, of course we're part of the community. (And yes, this realigns the point of view). gert -- 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/20100503/afcc88df/attachment.bin From tim at ripe.net Mon May 3 15:45:28 2010 From: tim at ripe.net (Tim Bruijnzeels) Date: Mon, 03 May 2010 15:45:28 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <1272891483.6612.147.camel@ntitley-laptop> References: <1272891483.6612.147.camel@ntitley-laptop> Message-ID: <4BDED378.5010303@ripe.net> On 5/3/10 2:58 PM, Nigel Titley wrote: > Folks > > Following this morning's discussion, here is my proposal for the slide > set. I think it roughly summarises the discussion. It may look a bit > bald, but the supporting patter should take the edge off. > > Comments and brickbats please. I know it is less than ideal, but we need > to get *something* agreed out there. > > Nigel > Hi Nigel, I agree with your summary. Please let me give you some technical answers to the proposal on slide #7. - certificates on request no problem - 3-5 year period no problem, we should keep an eye on CRLs growing and key lifetimes and adjust later if needed. - lax re-issue This implies that the RIPE NCC keeps providing services to ex-members in this specific case. There are some technicalities involved with this (access part of the portal and BPKI -- ensure that people can authenticate properly). These technicalities can be overcome, but ultimately this will require resources that normal members end up paying for. Is this what the community wants? - revoke on re-*assignment* not implement now, but can be done technically Regards, Tim From randy at psg.com Mon May 3 15:29:35 2010 From: randy at psg.com (Randy Bush) Date: Mon, 03 May 2010 15:29:35 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <20100503132250.GE60850@Space.Net> References: <1272891483.6612.147.camel@ntitley-laptop> <20100503132250.GE60850@Space.Net> Message-ID: > I like it. Clearly explain to the community why we're stuck, and what > the potential ways forward are. Then carefully prevent them from hanging > themselves... ourselves From robert at ripe.net Mon May 3 16:04:09 2010 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 03 May 2010 16:04:09 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <20100503132535.GF60850@Space.Net> References: <1272891483.6612.147.camel@ntitley-laptop> <4BDECD6D.8030101@ripe.net> <20100503132535.GF60850@Space.Net> Message-ID: <4BDED7D9.5080903@ripe.net> On 2010.05.03. 15:25, Gert Doering wrote: > Hi, > > On Mon, May 03, 2010 at 03:19:41PM +0200, Robert Kisteleki wrote: >> On slide 7: I think that the 3-5 year validity and the "reissue annually" >> are mutually exclusive. The reason why you want to have 3-5 years in the >> first place is to avoid the issues arising from not re-issuing. In other >> word, it doesn't make sense to re-issue if the previous certificate is still >> valid. > > Mabye "re-issue" is not the correct crypto word here. > > I know that in SSL web certificates, it's best current practice to > issue "new" certificates a few weeks before the "old" certificate runs > out (avoiding the term re-issue) - to give people a bit of slack to > upgrade their end, not having a flag day. That's one of the reasons, yes. > I think that's the point: not having a flag day where the old cert runs > out and a "somewhat lazy" LIR does not have time to install the new one > in time. What usually happens in SSL land is that the same keys are used for (usually) two cycles. That is, the expected lifetime of a key is two years, with two times one year certificates. So what's the idea in this context? If the very first issuance is for say 3 year, then what is the expected result of the re-issuance? Again 3 years? Because that'd overlap with the previous one for 2 years, and effectively make the key live for 4 years instead of 3. > So how to phrase that correct in terms of X.509 crypto? Renewal. Cheers, Robert > Gert Doering From andrei at ripe.net Mon May 3 16:28:08 2010 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 03 May 2010 16:28:08 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <1272891483.6612.147.camel@ntitley-laptop> References: <1272891483.6612.147.camel@ntitley-laptop> Message-ID: <4BDEDD78.7050407@ripe.net> Nigel, Nigel Titley wrote on 3/5/10 2:58 PM: > Folks > > Following this morning's discussion, here is my proposal for the slide > set. I think it roughly summarises the discussion. It may look a bit > bald, but the supporting patter should take the edge off. > > Comments and brickbats please. I know it is less than ideal, but we need > to get *something* agreed out there. > > Nigel > I am not sure if I am interpreting the proposal correctly (slide 7), but does "not tied to RIPE NCC membership" imply that the certificates are not based on business relationships between the holder and the RIPE NCC anymore? The 3-5 year validity period implies that we re-issue certificates also once in 3-5 years. That also means that the community is OK with the decreasing quality of the initial cert statement over this long period of time. IMO "Certificates revoked on address re-assignment" effectively means that only voluntarily returned space can be reclaimed. I am a bit worried that with these sacrifices we may decrease the utility of the resulting tool for routing security too much. Andrei From gert at space.net Mon May 3 16:32:11 2010 From: gert at space.net (Gert Doering) Date: Mon, 3 May 2010 16:32:11 +0200 Subject: [ca-tf] Policy proposal In-Reply-To: <4BDED7D9.5080903@ripe.net> References: <1272891483.6612.147.camel@ntitley-laptop> <4BDECD6D.8030101@ripe.net> <20100503132535.GF60850@Space.Net> <4BDED7D9.5080903@ripe.net> Message-ID: <20100503143211.GM60850@Space.Net> Hi, On Mon, May 03, 2010 at 04:04:09PM +0200, Robert Kisteleki wrote: > > So how to phrase that correct in terms of X.509 crypto? > > Renewal. Nigel, you're listening? :-) (As far as I have understood the debate, that's what we're after "make sure that the certificate doesn't run out all of a sudden", and if the X.509 word for that is "renewal", then that's the word we want to use). Gert Doering -- 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/20100503/9b18a77a/attachment.bin From nigel.titley at uk.easynet.net Mon May 3 16:45:42 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 03 May 2010 15:45:42 +0100 Subject: [ca-tf] Policy proposal In-Reply-To: <4BDED378.5010303@ripe.net> References: <1272891483.6612.147.camel@ntitley-laptop> <4BDED378.5010303@ripe.net> Message-ID: <1272897942.6612.160.camel@ntitley-laptop> On Mon, 2010-05-03 at 15:45 +0200, Tim Bruijnzeels wrote: > - lax re-issue > > This implies that the RIPE NCC keeps providing services to ex-members in > this specific case. There are some technicalities involved with this > (access part of the portal and BPKI -- ensure that people can > authenticate properly). These technicalities can be overcome, but > ultimately this will require resources that normal members end up paying > for. Is this what the community wants? Yes, this gives me the twitches too. But I think it is what we agreed. A response to this is to say "well if you don't like it then let's get the whole thing sorted out properly". Nigel From nigel.titley at uk.easynet.net Mon May 3 16:51:49 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 03 May 2010 15:51:49 +0100 Subject: [ca-tf] Policy proposal In-Reply-To: <20100503143211.GM60850@Space.Net> References: <1272891483.6612.147.camel@ntitley-laptop> <4BDECD6D.8030101@ripe.net> <20100503132535.GF60850@Space.Net> <4BDED7D9.5080903@ripe.net> <20100503143211.GM60850@Space.Net> Message-ID: <1272898309.6612.162.camel@ntitley-laptop> On Mon, 2010-05-03 at 16:32 +0200, Gert Doering wrote: > Hi, > > On Mon, May 03, 2010 at 04:04:09PM +0200, Robert Kisteleki wrote: > > > So how to phrase that correct in terms of X.509 crypto? > > > > Renewal. > > Nigel, you're listening? :-) Yes. > (As far as I have understood the debate, that's what we're after "make > sure that the certificate doesn't run out all of a sudden", and if the > X.509 word for that is "renewal", then that's the word we want to use). OK, that's a simple fix to the slide deck (and done) Nigel From nigel.titley at uk.easynet.net Mon May 3 16:59:08 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 03 May 2010 15:59:08 +0100 Subject: [ca-tf] Policy proposal In-Reply-To: <4BDEDD78.7050407@ripe.net> References: <1272891483.6612.147.camel@ntitley-laptop> <4BDEDD78.7050407@ripe.net> Message-ID: <1272898748.6612.169.camel@ntitley-laptop> On Mon, 2010-05-03 at 16:28 +0200, Andrei Robachevsky wrote: > Nigel, > > Nigel Titley wrote on 3/5/10 2:58 PM: > > Folks > > > > Following this morning's discussion, here is my proposal for the slide > > set. I think it roughly summarises the discussion. It may look a bit > > bald, but the supporting patter should take the edge off. > > > > Comments and brickbats please. I know it is less than ideal, but we need > > to get *something* agreed out there. > > > > Nigel > > > > I am not sure if I am interpreting the proposal correctly (slide 7), but > does "not tied to RIPE NCC membership" imply that the certificates are > not based on business relationships between the holder and the RIPE NCC > anymore? Yes. And this is manifestly non-optimal. However it may do as an interim policy, just to get this off the ground. > The 3-5 year validity period implies that we re-issue certificates also > once in 3-5 years. That also means that the community is OK with the > decreasing quality of the initial cert statement over this long period > of time. Yes, indeed it does. > IMO "Certificates revoked on address re-assignment" effectively means > that only voluntarily returned space can be reclaimed. Not at all. Under any condition in which the RIPE NCC would re-assign address space, they will revoke the original certificate and allow the new holder to request the issue of a new one. So using the existing operational procedures, the address will 1. Have been reclaimed by the RIPE NCC 2. Not been routed for 4 months If this is what you mean by voluntarily returned space then so be it. I would prefer to refer to it as uncontested reclaimed space. > I am a bit worried that with these sacrifices we may decrease the > utility of the resulting tool for routing security too much. We are all in agreement that this is a non optimal solution. However we will sit around until the sun is a cold, dead clinker unless we make some concessions. Nigel From nigel.titley at uk.easynet.net Mon May 3 17:03:19 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 03 May 2010 16:03:19 +0100 Subject: [ca-tf] Re: Policy proposal In-Reply-To: References: <1272891483.6612.147.camel@ntitley-laptop> Message-ID: <1272898999.6612.173.camel@ntitley-laptop> On Mon, 2010-05-03 at 15:07 +0200, Randy Bush wrote: > s/Competance/Competence/ Damm.... > Way Forward: decouple immediate (we wish) deployment from coming to > community convergence on forward policy Yes. I'll see if I can translate that into words of one syllable. > cool! > > randy From nigel.titley at uk.easynet.net Mon May 3 17:14:21 2010 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Mon, 03 May 2010 16:14:21 +0100 Subject: [ca-tf] Re: Policy proposal In-Reply-To: <1272898999.6612.173.camel@ntitley-laptop> References: <1272891483.6612.147.camel@ntitley-laptop> <1272898999.6612.173.camel@ntitley-laptop> Message-ID: <1272899661.6612.177.camel@ntitley-laptop> Folks, Updated slide deck. Nigel -------------- next part -------------- A non-text attachment was scrubbed... Name: 2008-08.pdf Type: application/pdf Size: 143031 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100503/017e560b/attachment.pdf From alexb at ripe.net Tue May 18 17:26:28 2010 From: alexb at ripe.net (Alex Band) Date: Tue, 18 May 2010 17:26:28 +0200 Subject: [ca-tf] Resource Certification ties to Registration Policy Message-ID: <7A4BAFA7-4F6D-44A7-AF67-482CA6526BE2@ripe.net> Dear Certification Task Force members, I would like to thank everyone for their input during RIPE60. There was a large amount of discussion in the CA-TF meeting, as well as the Address Policy Working Group session. Instead of covering all of the items in one single message, I would like to cover them one by one, in separate discussions. The first point I would like to bring up is our Address Policy, or rather Registration Policy. A statement was made that it is unclear and badly understood. A lot of arguments were made back and forth about the clarity of our registration policy and the business practices that stem from it. Information on this topic is not published in great detail on the RIPE website. The document that currently describes this is RIPE-301 (http://www.ripe.net/docs/mergers.html ). At the moment we are working on a new version, which after it has gone through the PDP, makes processes like closures crystal clear. The next step is to educate the membership about our processes, so they understand how Resource Certification fits into this. I will work with our Comms department to set out a strategy to do this. There seemed to be consensus that if registration policy is absolutely clear, there is no problem with certificate revocation when reclaiming address space. Can I verify with the CA-TF that this is the case? Kind regards, Alex Band Resource Certification Product Manager RIPE NCC From nigel at titley.com Thu May 6 16:53:00 2010 From: nigel at titley.com (Nigel Titley) Date: Thu, 06 May 2010 15:53:00 +0100 Subject: [ca-tf] 2008-08 Message-ID: <1273157580.16227.79.camel@ntitley-laptop> OK, now that some of the heat has died down and I've looked back on the session I would say that we had a certain amount of consensus for the following statements (and thank you Daniel for posing my first question in a less loaded form. There wasn't actually an intent to make it loaded) 1. Certificates should reflect the state of the registry 2. Certificates should be revoked when address space is reclaimed (or returned) Now, in my book, we are very close to version 1 of the policy and with some word-smithing, to remove the loaded "business relationship" aspects of the policy and to emphasise the reflection of the registry state I think we may get some community consensus. With your Lordships'/Ladyships' permissions I'll try and do this and circulate to this list. Does that suit? Nigel From axel.pawlik at ripe.net Tue May 25 15:13:37 2010 From: axel.pawlik at ripe.net (Axel Pawlik) Date: Tue, 25 May 2010 15:13:37 +0200 Subject: delayed mail (was :Re: [ca-tf] 2008-08) In-Reply-To: <1273157580.16227.79.camel@ntitley-laptop> References: <1273157580.16227.79.camel@ntitley-laptop> Message-ID: <4BFBCD01.5040705@ripe.net> All, I just found this delayed mail in my mailbox. On investigating, it turns out to have been stuck in the moderator's box, while the staff member moderating was on sick leave. We will see to improve procedures. just to let you know, Axel On 06/05/2010 16:53, Nigel Titley wrote: > OK, now that some of the heat has died down and I've looked back on the > session I would say that we had a certain amount of consensus for the > following statements (and thank you Daniel for posing my first question > in a less loaded form. There wasn't actually an intent to make it > loaded) > > 1. Certificates should reflect the state of the registry > 2. Certificates should be revoked when address space is reclaimed (or > returned) > > Now, in my book, we are very close to version 1 of the policy and with > some word-smithing, to remove the loaded "business relationship" aspects > of the policy and to emphasise the reflection of the registry state I > think we may get some community consensus. > > With your Lordships'/Ladyships' permissions I'll try and do this and > circulate to this list. Does that suit? > > Nigel > > > From henk at ripe.net Tue May 25 15:43:29 2010 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 25 May 2010 15:43:29 +0200 Subject: delayed mail (was :Re: [ca-tf] 2008-08) In-Reply-To: <4BFBCD01.5040705@ripe.net> References: <1273157580.16227.79.camel@ntitley-laptop> <4BFBCD01.5040705@ripe.net> Message-ID: <4BFBD401.9000501@ripe.net> All, > I just found this delayed mail in my mailbox. On investigating, > it turns out to have been stuck in the moderator's box, while > the staff member moderating was on sick leave. To avoid this from happening in the first place, please make sure that you use the same address for posting and reading the list, as the list is set up such that only subscribers can post. (This is to kill spam.) If you are not sure which address you have been using or want to change addresses, just let me know. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician.