From alexb at ripe.net Thu Apr 8 15:25:11 2010 From: alexb at ripe.net (Alex Band) Date: Thu, 8 Apr 2010 15:25:11 +0200 Subject: [ca-tf] RIPE Certification Task Force Meeting at RIPE 60 Message-ID: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> Dear Certification Task Force members, SInce this is my first post to the CA-TF mailing list, allow me to introduce myself. I'm Alex Band, formally a Trainer at the RIPE NCC, but since January I am spending the majority of my time on Resource Certification. Since Certification is a complex project involving the Community, the membership, the IETF, this Task Force, as well as several departments within the RIPE NCC, my goal is to be the single focal point who brings all these elements together. I would like to invite the RIPE Certification Task Force on the morning of Monday, 3 May, at 11:00 hrs in the main meeting room on site. In the past the meeting was an hour earlier, but I am delivering the IPv6 tutorial and Andrew is flying in during that time. Would that work for everyone? I am looking forward to your response. Kind regards, Alex Band RIPE NCC From gert at space.net Thu Apr 8 15:31:42 2010 From: gert at space.net (Gert Doering) Date: Thu, 8 Apr 2010 15:31:42 +0200 Subject: [ca-tf] RIPE Certification Task Force Meeting at RIPE 60 In-Reply-To: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> References: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> Message-ID: <20100408133142.GW69383@Space.Net> Hi, On Thu, Apr 08, 2010 at 03:25:11PM +0200, Alex Band wrote: > I would like to invite the RIPE Certification Task Force on the > morning of Monday, 3 May, at 11:00 hrs in the main meeting room on > site. In the past the meeting was an hour earlier, but I am delivering > the IPv6 tutorial and Andrew is flying in during that time. Would that > work for everyone? Most likely, I won't be able to attend this RIPE meeting, so I won't be able to attend the CA TF meeting either :-( 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 From dol at cryptocom.ru Thu Apr 8 15:35:38 2010 From: dol at cryptocom.ru (Basil Dolmatov) Date: Thu, 08 Apr 2010 17:35:38 +0400 Subject: [ca-tf] RIPE Certification Task Force Meeting at RIPE 60 In-Reply-To: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> References: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> Message-ID: <4BBDDBAA.9050603@cryptocom.ru> Alex Band ?????: > Dear Certification Task Force members, > > SInce this is my first post to the CA-TF mailing list, allow me to > introduce myself. > > I'm Alex Band, formally a Trainer at the RIPE NCC, but since January I > am spending the majority of my time on Resource Certification. Since > Certification is a complex project involving the Community, the > membership, the IETF, this Task Force, as well as several departments > within the RIPE NCC, my goal is to be the single focal point who brings > all these elements together. > > I would like to invite the RIPE Certification Task Force on the morning > of Monday, 3 May, at 11:00 hrs in the main meeting room on site. In the > past the meeting was an hour earlier, but I am delivering the IPv6 > tutorial and Andrew is flying in during that time. Would that work for > everyone? > Not for me... My plane will land in Prague airport at 18:00 3rd of May. From dburk at burkov.aha.ru Tue Apr 13 13:02:10 2010 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Tue, 13 Apr 2010 15:02:10 +0400 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> Message-ID: <4BC44F32.7080302@burkov.aha.ru> On 3/24/2010 11:48 PM, Sander Steffann wrote: > 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. > It is even more important to follow PDP especially now when we are in front of formation of new strong hierarchical system. It is very questionable issue. Dima > - Sander > > From henk at ripe.net Tue Apr 13 15:32:05 2010 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 13 Apr 2010 15:32:05 +0200 Subject: [ca-tf] Re: subscription In-Reply-To: <0C25F648-E400-4A84-9C92-E03E53FFF308@ripe.net> References: <4634554A-CFF1-4DDE-9128-EE5944499848@ripe.net> <4BC46E25.7060308@ripe.net> <0C25F648-E400-4A84-9C92-E03E53FFF308@ripe.net> Message-ID: <4BC47255.6070208@ripe.net> Hi, > In the meantime I think subscription is open to anyone here: > http://www.ripe.net/mailman/listinfo/ca-tf No, subscription requests are sent to the moderator (=me) who has to approve them. At least, that is how it used to work. 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From henk at ripe.net Tue Apr 13 15:44:35 2010 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 13 Apr 2010 15:44:35 +0200 Subject: [ca-tf] Re: subscription In-Reply-To: <4BC47255.6070208@ripe.net> References: <4634554A-CFF1-4DDE-9128-EE5944499848@ripe.net> <4BC46E25.7060308@ripe.net> <0C25F648-E400-4A84-9C92-E03E53FFF308@ripe.net> <4BC47255.6070208@ripe.net> Message-ID: <4BC47543.6060204@ripe.net> Please ignore, this should not have gone to the list. Henk On 13/04/2010 15:32, Henk Uijterwaal wrote: > Hi, > >> In the meantime I think subscription is open to anyone here: >> http://www.ripe.net/mailman/listinfo/ca-tf > > No, subscription requests are sent to the moderator (=me) who > has to approve them. At least, that is how it used to work. ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ Nobody ever went broke underestimating the taste of the American public. H.L.Mencken From Woeber at CC.UniVie.ac.at Tue Apr 13 15:43:01 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 13 Apr 2010 13:43:01 +0000 Subject: [ca-tf] Re: [certtest] rPKI vendor's implementation verfication In-Reply-To: <4BC42DD3.8080308@noc.ntua.gr> References: <4BC42DD3.8080308@noc.ntua.gr> Message-ID: <4BC474E5.3060605@CC.UniVie.ac.at> Hi Dimitis, have a look at: http://www.ripe.net/ripe/docs/asn-assignment.html#11 I think this should give you a path to persue your project? The contractual requirements, if you want to go down the road of PI, are "free of charge" (more or less), assuming that you can easily find a "friendly" LIR offering this service to you? The basic cost per "item", as charged by the NCC, is (currently) ?50,- p.a., aka "peanuts" :-) Hth, Wilfried. Dimitris Kalogeras wrote: > Hi *, > > Apologies for cross sending to mailing list. Allow me to introduce > myself. My name is Dimitris Kalogeras > (DK24-RIPE )and I work Network operation centre of NTUA ( a university > of Greece AS-3323). I am also collaborating with GRNET ( the Greek NREN > - AS5408). > > I am trying to get a pragmatic view of the rPKI infrastructure along > with the associated router functionality. I have arranged to participate > in a vendor's ( i.e. Cisco) beta testing with respect to rPKI. (As a > matter of fact I would invite any other vendor > who's is on the list and has a similar functionality to submit this for > testing.) > > Basically, I am thinking something like AS-ONE<------> > AS-two<----->AS5408 on terms of path topology. > AS5408 would have the role of transit provider, AS-two would have the > role of ISP and AS-one the role of a client. > Following, I would assign temporarily some address from the assignment > of GRNET to those ASes. > > I would be happy to report the results back into the mailing list or in > a ripe meeting. > > So I would like to ask from RIPE to generate two new AS for testing > purposes without getting charged because I would not > use them commercially but just for verification purposes . > > > Regards, > Dimitris > > From filiz at ripe.net Tue Apr 13 16:16:20 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 13 Apr 2010 16:16:20 +0200 Subject: Fwd: [ca-tf] Certification-Policy Proposal - next steps? References: Message-ID: <708911CF-B8E6-42C5-81C7-7D5E96CA636E@ripe.net> Hello, As the AP WG co-chair, it is important for Sander to follow the full discussion about the policy proposal. I have been informed that the following mail did not reach him. So I am passing Andrew's last full mail again to the list that was pointing to information about a possible new version of the certification proposal, as Sander's subscription to the list is confirmed. Regards, Filiz Begin forwarded message: > From: Andrew de la Haye > Date: 31 March 2010 10:37:43 GMT+02:00 > To: ca-tf at ripe.net > Cc: Axel Pawlik > Subject: Re: [ca-tf] Certification-Policy Proposal - next steps? > > 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/20100413/a4cf192e/attachment.html From nigel at titley.com Tue Apr 13 19:06:42 2010 From: nigel at titley.com (Nigel Titley) Date: Tue, 13 Apr 2010 18:06:42 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: References: Message-ID: <1271178402.3392.194.camel@ntitley-laptop> On Wed, 2010-03-31 at 10:37 +0200, Andrew de la Haye wrote: > Dear Certification Task Force members, > > > I am very happy that the discussion around this topic has come to life > like this. Nice when that happens, isn't it :-) > 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. One could make a number of philosophical points about what is truth, but I will confine myself to one. A certificate represents the truth at a particular point in time. In this case it represents the world view that the RIPE NCC believes to be "true" at the moment of issuing the certificate. Thereafter its value declines gradually over time until it is reissued again. > > 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. But going to my statement above, you are actually only attesting to the business relationship at a particular point in time. If the user is happy with the decaying relationship of the certificate over time, then I'm not sure what the RIPE NCC has to worry about. > 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 So, at this point, you revoke the certificate. With appropriate precautions. > > 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. Again, as above. When you recover the resource, you revoke the certificate. > > 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. This helps, but why not issue the certificate with a long expiry and revoke when absolutely necessary? > > 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 The problem with this approach is that it leads to the same sort of problems we see with RBLs. Some RBLs are better operated than others, but the average operator may not understand this and may end up blocking email based on a badly operated RBL. When you query this you just end up with the response "well you are on this RBL so you must be a spammer". I can see similar things happening with certification. > 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 But as above, how many will actually understand what they are doing? > 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. Well, doubts have been expressed in a number of quarters about the lack of the up/down protocol in your implementation. The feeling is that the portal solution only addresses part of the problem. > 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 See above. Same problem. > 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. This indeed does help with giving me a warm, damp feeling. But we need to make it crystal clear to the community that they are free to ignore certificates... and then where does that give us improved routing security? > > 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 Well, I know for a fact that in the APNIC region the members have had similar misgivings about certification. If this is all sorted out and everyone is happy, then good. I had the impression that it wasn't however. > 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 I really don't think this goes far enough. I think we will have greater chance of selling the product if we *slightly* decouple the certificates from the membership status. And the simplest way of doing this is to lengthen the certificate expiry time. > > Naturally, the RIPE NCC is more than happy to support drafting a > proposal. Taken as read... I suggest we get together early on at Prague, but preferably come up with a straw man on this list. Nigel From gert at space.net Wed Apr 14 11:52:18 2010 From: gert at space.net (Gert Doering) Date: Wed, 14 Apr 2010 11:52:18 +0200 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1271178402.3392.194.camel@ntitley-laptop> References: <1271178402.3392.194.camel@ntitley-laptop> Message-ID: <20100414095218.GA98913@Space.Net> Hi, On Tue, Apr 13, 2010 at 06:06:42PM +0100, Nigel Titley wrote: > On Wed, 2010-03-31 at 10:37 +0200, Andrew de la Haye wrote: > > Dear Certification Task Force members, > > > > I am very happy that the discussion around this topic has come to life > > like this. > > Nice when that happens, isn't it :-) [..] I think most of the important positions have been exchanged now (and I very much agree with Nigel: crucial for the success for this is how we handle the concerns from the community). Now is the question: what is the way forward? I'm asking this wearing the APWG chair hat - "there is a proposal, there is a meeting coming up, we need to make use of the opportunity to talk to the community". It would be good to have a new revision available by next week, so that people have something to think over while preparing for the RIPE meeting, and that we can discuss the way forward on the list and at the meeting. (Sander will steer the meeting, as I won't be able to attend, so it's important to synchronize with him on how to present and what are the questions that we want answers from the community) Gert Doering -- wearing the APWG chair hat, pushing the proposer(s) to go ahead -- 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/20100414/fb2e039e/attachment.bin From gert at space.net Wed Apr 14 12:27:11 2010 From: gert at space.net (Gert Doering) Date: Wed, 14 Apr 2010 12:27:11 +0200 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <1271239906.3392.280.camel@ntitley-laptop> References: <1271178402.3392.194.camel@ntitley-laptop> <20100414095218.GA98913@Space.Net> <1271239906.3392.280.camel@ntitley-laptop> Message-ID: <20100414102711.GF69383@Space.Net> Hi, On Wed, Apr 14, 2010 at 11:11:46AM +0100, Nigel Titley wrote: [..] > > Now is the question: what is the way forward? > > My suggestion would be that we slightly rework the proposal to add the > following: > > 1. Certificates will have a validity of 5 years > 2. Certificates will be revoked when the resources are re-allocated [..] > Could I suggest that Filiz and I work together to do this? Shouldn't > take too long and we can come back with the results to this task force. This would work for me (with both the AP chair hat on regarding "procedures" and also with the "affected community member" glasses). Not everybody will be happy, of course, but that's the way compromises work. 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/20100414/d69f0e76/attachment.bin From nigel at titley.com Wed Apr 14 12:11:46 2010 From: nigel at titley.com (Nigel Titley) Date: Wed, 14 Apr 2010 11:11:46 +0100 Subject: [ca-tf] Certification-Policy Proposal - next steps? In-Reply-To: <20100414095218.GA98913@Space.Net> References: <1271178402.3392.194.camel@ntitley-laptop> <20100414095218.GA98913@Space.Net> Message-ID: <1271239906.3392.280.camel@ntitley-laptop> On Wed, 2010-04-14 at 11:52 +0200, Gert Doering wrote: > I think most of the important positions have been exchanged now (and > I very much agree with Nigel: crucial for the success for this is how > we handle the concerns from the community). > > Now is the question: what is the way forward? My suggestion would be that we slightly rework the proposal to add the following: 1. Certificates will have a validity of 5 years 2. Certificates will be revoked when the resources are re-allocated We could also add some warm fuzzy stuff about only revoking certificates for legal reasons when the Dutch police actually have Axel/Andrew banged up in a cell for contempt of court. I think the above will be perceived as enough "give" for us to get consensus. I know it isn't a perfect state of affairs, and I fully see Andrew's points about fitting in with the RIPE NCC's business processes, but we need to make some concessions. Could I suggest that Filiz and I work together to do this? Shouldn't take too long and we can come back with the results to this task force. Nigel From tim at ripe.net Mon Apr 26 14:27:14 2010 From: tim at ripe.net (Tim Bruijnzeels) Date: Mon, 26 Apr 2010 14:27:14 +0200 Subject: [ca-tf] Draft CPS, please have a look Message-ID: <4BD586A2.5030407@ripe.net> Dear colleagues, as requested before by Ruediger we would like to send you the 'CPS' that we have been working on. This 'Certification Practice Statement' describes the *technical* implementation that for the member facing RPKI Certificate Authority of the RIPE NCC. Please note that this is *not* intended to be a RIPE community Certification Policy document. It is a required PKI document that follows the 'Certificate Policy' document defined in the IETF SIDR-WG. This instance of the word 'policy' should be taken in the PKI context. Please have a look at this draft CPS and let us know if you have any questions or comments. In particular if you see anything that you feel may not be inline with the envisioned community policy. It is important that we address this sooner, rather than later to ensure that we will have enough time to finalise the implementation before intended go-live 1 Jan 2011. Regards, Tim Bruijnzeels Senior Software Developer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: rpki-cps.pdf Type: application/pdf Size: 196174 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20100426/91515642/attachment.pdf From alexb at ripe.net Tue Apr 27 10:33:15 2010 From: alexb at ripe.net (Alex Band) Date: Tue, 27 Apr 2010 10:33:15 +0200 Subject: [ca-tf] RIPE Certification Task Force Meeting at RIPE 60 In-Reply-To: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> References: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> Message-ID: <39E015DD-FBA0-4420-9717-629BECEE6D85@ripe.net> Dear colleagues, I would like to reconfirm that the RIPE Certification Task Force meeting will be held on the morning of Monday, 3 May, at 11:00 hrs in the main meeting room on site. I tried to accomodate for Basil's schedule, but that proved to be impossible to arrange. Kind regards, Alex Band RIPE NCC On 8 Apr 2010, at 15:25, Alex Band wrote: > Dear Certification Task Force members, > > SInce this is my first post to the CA-TF mailing list, allow me to > introduce myself. > > I'm Alex Band, formally a Trainer at the RIPE NCC, but since January > I am spending the majority of my time on Resource Certification. > Since Certification is a complex project involving the Community, > the membership, the IETF, this Task Force, as well as several > departments within the RIPE NCC, my goal is to be the single focal > point who brings all these elements together. > > I would like to invite the RIPE Certification Task Force on the > morning of Monday, 3 May, at 11:00 hrs in the main meeting room on > site. In the past the meeting was an hour earlier, but I am > delivering the IPv6 tutorial and Andrew is flying in during that > time. Would that work for everyone? > > I am looking forward to your response. > > Kind regards, > > Alex Band > RIPE NCC > > From sander at steffann.nl Tue Apr 27 11:17:07 2010 From: sander at steffann.nl (Sander Steffann) Date: Tue, 27 Apr 2010 11:17:07 +0200 Subject: [ca-tf] RIPE Certification Task Force Meeting at RIPE 60 In-Reply-To: <39E015DD-FBA0-4420-9717-629BECEE6D85@ripe.net> References: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> <39E015DD-FBA0-4420-9717-629BECEE6D85@ripe.net> Message-ID: Hi Alex / TF, > I would like to reconfirm that the RIPE Certification Task Force meeting will be held on the morning of Monday, 3 May, at 11:00 hrs in the main meeting room on site. I tried to accomodate for Basil's schedule, but that proved to be impossible to arrange. FYI: Because Gert will not be in Prague I will be taking his place for this meeting. Thanks, - Sander From dburk at burkov.aha.ru Tue Apr 27 11:29:27 2010 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Tue, 27 Apr 2010 13:29:27 +0400 Subject: [ca-tf] RIPE Certification Task Force Meeting at RIPE 60 In-Reply-To: <39E015DD-FBA0-4420-9717-629BECEE6D85@ripe.net> References: <68E9FD79-4F3C-46D4-AE32-1C8BCAA7F47E@ripe.net> <39E015DD-FBA0-4420-9717-629BECEE6D85@ripe.net> Message-ID: <4BD6AE77.8030301@burkov.aha.ru> On 27.04.2010 12:33, Alex Band wrote: > Dear colleagues, > > I would like to reconfirm that the RIPE Certification Task Force > meeting will be held on the morning of Monday, 3 May, at 11:00 hrs in > the main meeting room on site. I tried to accomodate for Basil's > schedule, but that proved to be impossible to arrange. I will try to substitute Basil, if it is possible :-) Dmitry > > Kind regards, > > Alex Band > RIPE NCC > > On 8 Apr 2010, at 15:25, Alex Band wrote: > >> Dear Certification Task Force members, >> >> SInce this is my first post to the CA-TF mailing list, allow me to >> introduce myself. >> >> I'm Alex Band, formally a Trainer at the RIPE NCC, but since January >> I am spending the majority of my time on Resource Certification. >> Since Certification is a complex project involving the Community, the >> membership, the IETF, this Task Force, as well as several departments >> within the RIPE NCC, my goal is to be the single focal point who >> brings all these elements together. >> >> I would like to invite the RIPE Certification Task Force on the >> morning of Monday, 3 May, at 11:00 hrs in the main meeting room on >> site. In the past the meeting was an hour earlier, but I am >> delivering the IPv6 tutorial and Andrew is flying in during that >> time. Would that work for everyone? >> >> I am looking forward to your response. >> >> Kind regards, >> >> Alex Band >> RIPE NCC >> >> >