From filiz at ripe.net Thu Oct 2 13:29:59 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 2 Oct 2008 13:29:59 +0200 Subject: [ca-tf] last version of the Certification Proposal Message-ID: Hi CA TF members, As promised, after consultation with Ruediger and Nigel, regarding Ruediger's comments on the previous version, attached please find a new version of the Certification Proposal. Main differences from the previous one are the following: - This one talks about "contractual relationship status" instead of "membership status" for LIRs to be able to maintain the service they receive from the NCC. - It sets a specific validity period for certificates (up to 18 months). - There is an additional paragraph at the beginning now, elaborating on that this policy is only limited to LIR PA allocations (the reason for that is explained in Rationale already). Please pass your objections (if any) to this version's wording until 10 October 2008, Friday, next week. Support mails will be appreciated but I will take silence as consent :). After that I will proceed with the publication of it as a formal proposal, when I will have just enough but limited time before RIPE 57. Please note by that time we will have only two weeks before the meeting in Dubai. In other words, to have the proposal as a formal one as announced in RIPE 56, it is very important to stick to the deadline above, 10 October 2008. It will also be good to have it discussed for at least a week before it is presented during the meeting. Kind regards, Filiz Yilmaz Policy Development Officer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft04.doc Type: application/octet-stream Size: 28160 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20081002/8f590b78/attachment.obj -------------- next part -------------- From daniel.karrenberg at ripe.net Fri Oct 3 05:26:58 2008 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 3 Oct 2008 05:26:58 +0200 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: References: Message-ID: <20081003032658.GD474@reiftel.local> Short and sweet. This should be proposed. Daniel In my version of english it is "in line" and not inline. From robert at ripe.net Sun Oct 5 18:09:11 2008 From: robert at ripe.net (Robert Kisteleki) Date: Sun, 05 Oct 2008 18:09:11 +0200 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: <20081003032658.GD474@reiftel.local> References: <20081003032658.GD474@reiftel.local> Message-ID: <48E8E6A7.8080606@ripe.net> I second this - I like the current contents. I have only one note: personally I'm not in favor of explicitly mentioning the LIR portal as *the* secure communication channel, as that seems to be more like an implementation issue. But, as I said, I'm also OK if it stays as it is now. Cheers, Robert Daniel Karrenberg wrote: > Short and sweet. This should be proposed. > > Daniel > > In my version of english it is "in line" and not inline. From rv at NIC.DTAG.DE Fri Oct 10 10:38:58 2008 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Fri, 10 Oct 2008 10:38:58 +0200 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: Your message of "Thu, 02 Oct 2008 13:29:59 +0200." Message-ID: <27238.1223627938@x37.NIC.DTAG.DE> Dear Filiz, dear colleagues, > Hi CA TF members, > > As promised, after consultation with Ruediger and Nigel, regarding > Ruediger's comments on the previous version, attached please find a > new version of the Certification Proposal. > > Main differences from the previous one are the following: > > - This one talks about "contractual relationship status" instead of > "membership status" for LIRs to be able to maintain the service they > receive from the NCC. > > - It sets a specific validity period for certificates (up to 18 months). > > - There is an additional paragraph at the beginning now, elaborating > on that this policy is only limited to LIR PA allocations (the reason > for that is explained in Rationale already). > > > Please pass your objections (if any) to this version's wording until > 10 October 2008, Friday, next week. Support mails will be appreciated > but I will take silence as consent :). > > After that I will proceed with the publication of it as a formal > proposal, when I will have just enough but limited time before RIPE > 57. Please note by that time we will have only two weeks before the > meeting in Dubai. In other words, to have the proposal as a formal > one as announced in RIPE 56, it is very important to stick to the > deadline above, 10 October 2008. It will also be good to have it > discussed for at least a week before it is presented during the meeting. > > Kind regards, > > Filiz Yilmaz > Policy Development Officer > RIPE NCC please find below a modified draft according to what I really would like to see. I guess the language of my small changes makes my point better then previous long messages. ("small changes" = few words, the semantic change is bigger:-) (Of course lots of additional words could be used about the tradeoffs...) I certainly think that starting the policy process is more important now than the exact language of the proposal; some discussion should be expected anyway. Best regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft-rv-diff.pdf Type: application/pdf Size: 40688 bytes Desc: proposal_in_template_draft-rv-diff.pdf Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20081010/2730604a/attachment.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft-rv.pdf Type: application/pdf Size: 38493 bytes Desc: proposal_in_template_draft-rv.pdf Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20081010/2730604a/attachment-0001.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft-rv.doc Type: application/msword Size: 26624 bytes Desc: proposal_in_template_draft-rv.doc Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20081010/2730604a/attachment.doc From dol at cryptocom.ru Fri Oct 10 11:31:35 2008 From: dol at cryptocom.ru (Basil Dolmatov) Date: Fri, 10 Oct 2008 13:31:35 +0400 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: <48E8E6A7.8080606@ripe.net> References: <20081003032658.GD474@reiftel.local> <48E8E6A7.8080606@ripe.net> Message-ID: <48EF20F7.8040307@cryptocom.ru> Seconded on Robert's remark about secure channel. Current LIR portal is *NOT* secure, so it should not be called such. === The certificate will be issued via a secure channel that the RIPE NCC maintains for its members (at the time of system deployment using of LIR Portal is considered possible for the sake of simplicity of transition process) with a validity period of up to 18 months. === Robert Kisteleki ?????: > I second this - I like the current contents. I have only one note: > personally I'm not in favor of explicitly mentioning the LIR portal as > *the* secure communication channel, as that seems to be more like an > implementation issue. But, as I said, I'm also OK if it stays as it is now. > > Cheers, > Robert > > > Daniel Karrenberg wrote: >> Short and sweet. This should be proposed. >> >> Daniel >> >> In my version of english it is "in line" and not inline. > > From nigel.titley at uk.easynet.net Fri Oct 10 11:35:05 2008 From: nigel.titley at uk.easynet.net (Nigel Titley) Date: Fri, 10 Oct 2008 10:35:05 +0100 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: <27238.1223627938@x37.NIC.DTAG.DE> References: <27238.1223627938@x37.NIC.DTAG.DE> Message-ID: <48EF21C9.6080304@uk.easynet.net> Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: > please find below a modified draft according to what I really would like to see. > I guess the language of my small changes makes my point better then > previous long messages. ("small changes" = few words, the semantic change > is bigger:-) > (Of course lots of additional words could be used about the tradeoffs...) > > I certainly think that starting the policy process is more important now than > the exact language of the proposal; some discussion should be expected > anyway. > If I can summarise your changes as I see them: 1. You want to clarify that if a PA allocation is returned for some reason, then the associated certificate is revoked but that the manner of doing this is outside of scope 2. You wish to clarify that certificates won't be arbitrarily revoked 3. You make a point about certificates being reissued after a dispute to represent the resolution of the dispute. I think that 1. could be usefully addressed, although it may seem a bit self evident. 3. is a valid point, but I think it is important not to go too deeply into the operational details in this proposal. Likewise I feel that 2. is adequately covered by the policy as currently stated. Thoughts anyone? Nigel From rv at nic.dtag.de Fri Oct 10 14:49:18 2008 From: rv at nic.dtag.de (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Fri, 10 Oct 2008 14:49:18 +0200 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: Your message of "Fri, 10 Oct 2008 10:35:05 BST." <48EF21C9.6080304@uk.easynet.net> Message-ID: <27465.1223642958@x37.NIC.DTAG.DE> Nigel, thanks for your comments. > Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: > > please find below a modified draft according to what I really would like to see. > > I guess the language of my small changes makes my point better then > > previous long messages. ("small changes" = few words, the semantic change > > is bigger:-) > > (Of course lots of additional words could be used about the tradeoffs...) > > > > I certainly think that starting the policy process is more important now han > > the exact language of the proposal; some discussion should be expected > > anyway. > > > If I can summarise your changes as I see them: > > 1. You want to clarify that if a PA allocation is returned for some > reason, then the associated certificate is revoked but that the manner > of doing this is outside of scope > 2. You wish to clarify that certificates won't be arbitrarily revoked + I'm happy that process and burden on NCC actually can be simplified while improving predictability for all the good players - extending a free ride by a few months for the minority of bad players does not seem a serious drawback. > 3. You make a point about certificates being reissued after a dispute to > represent the resolution of the dispute. it's not about handling a "dispute". It's about handling a security compromise after which certificates depending on a compromised key will be revoked. (When writing I essentially had in mind dealing with disaster hitting the NCC - looking at it now I'm actually happy that the language seems to be very very supportive to the address holder, and I think that's good!) Even if disaster is unlikely it certainly is a good thing to have the basic rules for dealing with it well defined and known ("In the unlikely event of loss of cabin pressure...") > I think that 1. could be usefully addressed, although it may seem a bit > self evident. Yes, it looks somewhat self evident. It helps to explicitly state all relevant certificate transistions (initial creation, renewal, expiration, revocation) with their conditions - which seems to be a good thing if the complete text stays short and simple. > 3. is a valid point, but I think it is important not to go > too deeply into the operational details in this proposal. Likewise I > feel that 2. is adequately covered by the policy as currently stated. > > Thoughts anyone? > > Nigel Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From filiz at ripe.net Thu Oct 16 11:13:16 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 16 Oct 2008 11:13:16 +0200 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: <27465.1223642958@x37.NIC.DTAG.DE> References: <27465.1223642958@x37.NIC.DTAG.DE> Message-ID: <97BBB424-6232-402C-B6BA-54D4C4E4B034@ripe.net> Hello, After these comments, Nigel kindly edited the proposal text for a new version as attached. I think the wording is not very brief but as mentioned by others too, it is more important to get this out for community review asap now. Hopefully it can be improved after community's review over it. I will publish the attached version before the end of the day. Thanks everyone for their input. Regards, Filiz -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal_in_template_draft06.doc Type: application/octet-stream Size: 30208 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20081016/9845db79/attachment.obj -------------- next part -------------- On 10 Oct 2008, at 14:49, Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: > Nigel, thanks for your comments. > >> Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: >>> please find below a modified draft according to what I really >>> would like to see. >>> I guess the language of my small changes makes my point better then >>> previous long messages. ("small changes" = few words, the >>> semantic change >>> is bigger:-) >>> (Of course lots of additional words could be used about the >>> tradeoffs...) >>> >>> I certainly think that starting the policy process is more >>> important now han >>> the exact language of the proposal; some discussion should be >>> expected >>> anyway. >>> >> If I can summarise your changes as I see them: >> >> 1. You want to clarify that if a PA allocation is returned for some >> reason, then the associated certificate is revoked but that the >> manner >> of doing this is outside of scope > > >> 2. You wish to clarify that certificates won't be arbitrarily revoked > + I'm happy that process and burden on NCC actually can be simplified > while improving predictability for all the good players - > extending a free ride by a few months for the minority of bad players > does not seem a serious drawback. > >> 3. You make a point about certificates being reissued after a >> dispute to >> represent the resolution of the dispute. > it's not about handling a "dispute". > It's about handling a security compromise after which certificates > depending on a compromised key will be revoked. > (When writing I essentially had in mind dealing with disaster > hitting the NCC > - looking at it now I'm actually happy that the language seems to > be very > very supportive to the address holder, and I think that's good!) > Even if disaster is unlikely it certainly is a good thing to have the > basic rules for dealing with it well defined and known > ("In the unlikely event of loss of cabin pressure...") > >> I think that 1. could be usefully addressed, although it may seem >> a bit >> self evident. > Yes, it looks somewhat self evident. It helps to explicitly state > all relevant certificate transistions (initial creation, renewal, > expiration, > revocation) with their conditions - which seems to be a good thing if > the complete text stays short and simple. > >> 3. is a valid point, but I think it is important not to go >> too deeply into the operational details in this proposal. Likewise I >> feel that 2. is adequately covered by the policy as currently stated. >> >> Thoughts anyone? >> >> Nigel > > Regards, > Ruediger > > > Ruediger Volk > > Deutsche Telekom AG -- Internet Backbone Engineering > > E-Mail: rv at NIC.DTAG.DE > From dol at cryptocom.ru Thu Oct 16 12:44:58 2008 From: dol at cryptocom.ru (Basil Dolmatov) Date: Thu, 16 Oct 2008 14:44:58 +0400 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: <97BBB424-6232-402C-B6BA-54D4C4E4B034@ripe.net> References: <27465.1223642958@x37.NIC.DTAG.DE> <97BBB424-6232-402C-B6BA-54D4C4E4B034@ripe.net> Message-ID: <48F71B2A.5020306@cryptocom.ru> I wonder whether my previous letter was seen in the list. If not, I can resend it, if yes, I would like to understand where I was wrong in my proposals, supporting Robert's comments. I failed to see any changes in the proposal concerning the so called "secure channel". Thanks in advance, dol@ Filiz Yilmaz ?????: > > Hello, > > After these comments, Nigel kindly edited the proposal text for a new > version as attached. > I think the wording is not very brief but as mentioned by others too, it > is more important to get this out for community review asap now. > Hopefully it can be improved after community's review over it. I will > publish the attached version before the end of the day. > > Thanks everyone for their input. > > Regards, > Filiz > > > > On 10 Oct 2008, at 14:49, Ruediger Volk, Deutsche Telekom T-Com - > TE141-P1 wrote: > >> Nigel, thanks for your comments. >> >>> Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: >>>> please find below a modified draft according to what I really would >>>> like to see. >>>> I guess the language of my small changes makes my point better then >>>> previous long messages. ("small changes" = few words, the semantic >>>> change >>>> is bigger:-) >>>> (Of course lots of additional words could be used about the >>>> tradeoffs...) >>>> >>>> I certainly think that starting the policy process is more important >>>> now han >>>> the exact language of the proposal; some discussion should be expected >>>> anyway. >>>> >>> If I can summarise your changes as I see them: >>> >>> 1. You want to clarify that if a PA allocation is returned for some >>> reason, then the associated certificate is revoked but that the manner >>> of doing this is outside of scope >> >> >>> 2. You wish to clarify that certificates won't be arbitrarily revoked >> + I'm happy that process and burden on NCC actually can be simplified >> while improving predictability for all the good players - >> extending a free ride by a few months for the minority of bad players >> does not seem a serious drawback. >> >>> 3. You make a point about certificates being reissued after a dispute to >>> represent the resolution of the dispute. >> it's not about handling a "dispute". >> It's about handling a security compromise after which certificates >> depending on a compromised key will be revoked. >> (When writing I essentially had in mind dealing with disaster hitting >> the NCC >> - looking at it now I'm actually happy that the language seems to be very >> very supportive to the address holder, and I think that's good!) >> Even if disaster is unlikely it certainly is a good thing to have the >> basic rules for dealing with it well defined and known >> ("In the unlikely event of loss of cabin pressure...") >> >>> I think that 1. could be usefully addressed, although it may seem a bit >>> self evident. >> Yes, it looks somewhat self evident. It helps to explicitly state >> all relevant certificate transistions (initial creation, renewal, >> expiration, >> revocation) with their conditions - which seems to be a good thing if >> the complete text stays short and simple. >> >>> 3. is a valid point, but I think it is important not to go >>> too deeply into the operational details in this proposal. Likewise I >>> feel that 2. is adequately covered by the policy as currently stated. >>> >>> Thoughts anyone? >>> >>> Nigel >> >> Regards, >> Ruediger >> >> >> Ruediger Volk >> >> Deutsche Telekom AG -- Internet Backbone Engineering >> >> E-Mail: rv at NIC.DTAG.DE >> From filiz at ripe.net Thu Oct 16 13:29:24 2008 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 16 Oct 2008 13:29:24 +0200 Subject: [ca-tf] last version of the Certification Proposal In-Reply-To: <48F71B2A.5020306@cryptocom.ru> References: <27465.1223642958@x37.NIC.DTAG.DE> <97BBB424-6232-402C-B6BA-54D4C4E4B034@ripe.net> <48F71B2A.5020306@cryptocom.ru> Message-ID: <4B90CF8D-C49A-4D5D-A1AA-FDD997A00DC6@ripe.net> Dear Basil, I have seen your mail. I understand that you do not find LIR Portal secure however, the proposal does not state it is secure. It rather says a secure channel will be used and at the time the proposal was written this medium is considered to be LIR Portal by the CA TF members (as there is no other medium known currently). Regarding the exact wording, like I mentioned before, more comments will be received from the community once the proposal is published. At this point, the understanding was to have the proposal published asap so that community will have the chance to review it at least a week before Dubai meeting. Kind regards, Filiz On 16 Oct 2008, at 12:44, Basil Dolmatov wrote: > I wonder whether my previous letter was seen in the list. > If not, I can resend it, if yes, I would like to understand where I > was wrong in my proposals, supporting Robert's comments. > I failed to see any changes in the proposal concerning the so > called "secure channel". > > > Thanks in advance, > dol@ > > > Filiz Yilmaz ?????: >> Hello, >> After these comments, Nigel kindly edited the proposal text for a >> new version as attached. >> I think the wording is not very brief but as mentioned by others >> too, it is more important to get this out for community review >> asap now. >> Hopefully it can be improved after community's review over it. I >> will publish the attached version before the end of the day. >> Thanks everyone for their input. >> Regards, >> Filiz >> On 10 Oct 2008, at 14:49, Ruediger Volk, Deutsche Telekom T-Com - >> TE141-P1 wrote: >>> Nigel, thanks for your comments. >>> >>>> Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: >>>>> please find below a modified draft according to what I really >>>>> would like to see. >>>>> I guess the language of my small changes makes my point better >>>>> then >>>>> previous long messages. ("small changes" = few words, the >>>>> semantic change >>>>> is bigger:-) >>>>> (Of course lots of additional words could be used about the >>>>> tradeoffs...) >>>>> >>>>> I certainly think that starting the policy process is more >>>>> important now han >>>>> the exact language of the proposal; some discussion should be >>>>> expected >>>>> anyway. >>>>> >>>> If I can summarise your changes as I see them: >>>> >>>> 1. You want to clarify that if a PA allocation is returned for some >>>> reason, then the associated certificate is revoked but that the >>>> manner >>>> of doing this is outside of scope >>> >>> >>>> 2. You wish to clarify that certificates won't be arbitrarily >>>> revoked >>> + I'm happy that process and burden on NCC actually can be >>> simplified >>> while improving predictability for all the good players - >>> extending a free ride by a few months for the minority of bad >>> players >>> does not seem a serious drawback. >>> >>>> 3. You make a point about certificates being reissued after a >>>> dispute to >>>> represent the resolution of the dispute. >>> it's not about handling a "dispute". >>> It's about handling a security compromise after which certificates >>> depending on a compromised key will be revoked. >>> (When writing I essentially had in mind dealing with disaster >>> hitting the NCC >>> - looking at it now I'm actually happy that the language seems to >>> be very >>> very supportive to the address holder, and I think that's good!) >>> Even if disaster is unlikely it certainly is a good thing to have >>> the >>> basic rules for dealing with it well defined and known >>> ("In the unlikely event of loss of cabin pressure...") >>> >>>> I think that 1. could be usefully addressed, although it may >>>> seem a bit >>>> self evident. >>> Yes, it looks somewhat self evident. It helps to explicitly state >>> all relevant certificate transistions (initial creation, renewal, >>> expiration, >>> revocation) with their conditions - which seems to be a good >>> thing if >>> the complete text stays short and simple. >>> >>>> 3. is a valid point, but I think it is important not to go >>>> too deeply into the operational details in this proposal. >>>> Likewise I >>>> feel that 2. is adequately covered by the policy as currently >>>> stated. >>>> >>>> Thoughts anyone? >>>> >>>> Nigel >>> >>> Regards, >>> Ruediger >>> >>> >>> Ruediger Volk >>> >>> Deutsche Telekom AG -- Internet Backbone Engineering >>> >>> E-Mail: rv at NIC.DTAG.DE >>>