From andrew at ripe.net Fri Feb 2 17:36:57 2007 From: andrew at ripe.net (Andrew de la Haye) Date: Fri, 02 Feb 2007 17:36:57 +0100 Subject: [ca-tf] CA-TF Workshop in Amsterdam - 13 February 2007 - Agenda & Logistics Message-ID: <45C368A9.5010704@ripe.net> Dear Colleagues, Tuesday 13 February 2007 we will have our CA-TF workshop in Amsterdam (Sheraton Schiphol). The proposed agenda: 10.30 Welcome 11.00 Introduction 11.15 Technical Prototype Status & Planning (including Demo) 12.30 Walk through of Identified Processes & Services - Discussion on impact and value 13.00 Lunch 13.30 Walk through of Identified Processes & Services - Discussion on impact and value 16.00 Drinks Pre-read documentation will be send to you on Tuesday 6 February. If you have any questions, please let me know. Kind regards, Andrew de la Haye From andrew at ripe.net Wed Feb 7 09:54:08 2007 From: andrew at ripe.net (Andrew de la Haye) Date: Wed, 07 Feb 2007 09:54:08 +0100 Subject: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February Message-ID: <45C993B0.8090704@ripe.net> Dear all, attached you will find a draft document intended as an initial summary of the processes that will be affected or created by the introduction of certification. It is not exhaustive, however, it gives an indication of the changes and issues that will need to be considered in implementing a certification service. By the end of this week an additional document will be provided, containing open generic and very specific questions and discussion items. If you have any remarks, please let me know. Regards, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 070206 Outline New and Current Services Affected by Certification v1.5.doc Type: application/msword Size: 124416 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20070207/74df3f58/attachment.doc From andrew at ripe.net Mon Feb 12 15:02:11 2007 From: andrew at ripe.net (Andrew de la Haye) Date: Mon, 12 Feb 2007 15:02:11 +0100 Subject: [ca-tf] CA-TF meeting tomorrow Tuesday 13 February (venue & travel policy) Message-ID: <45D07363.1040904@ripe.net> Colleagues, The venue of our CA-TF meeting is the Sheraton Amsterdam Schiphol. The hotel has direct access to Schiphol International Airport's arrival and departure hall. http://www.starwoodhotels.com/sheraton/property/overview/index.html?propertyID=301&EM=EPS_English_SH_301_NWE We have seen some unclarity around the 'travel policy' for this meeting. To ensure clarity for next meetings, we would like to propose the following: Everybody will book their own tickets and hotel if necessary. All costs will be reimbursed. When we announce the next meeting, we will also make a suggestion for a hotel. For reimbursements of the costs, the invoices can be sent to the RIPE NCC, to the attention of Dani?lla Coutinho. Please make sure that you provide us with your bank details, including BIC/Swift codes for international payments. You can send you invoices scanned by e-mail to Dani?lla (daniella at ripe.net) or via the normal post: RIPE NCC Attn: Dani?lla Coutinho Singel 258 1016 AB Amsterdam The Netherlands If you for some reason can not make your own arrangements, the RIPE NCC is happy to assist. Please contact us in that case. Please let us know if you have any further questions. Kind regards From leo.vegoda at icann.org Mon Feb 12 16:12:30 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 12 Feb 2007 16:12:30 +0100 Subject: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <45C993B0.8090704@ripe.net> References: <45C993B0.8090704@ripe.net> Message-ID: Hi Andrew, On Feb 7, 2007, at 9:54 AM, Andrew de la Haye wrote: [...] > By the end of this week an additional document will be provided, > containing open generic and very specific questions and discussion > items. Was this document sent? I can't see it in the mail archive on the web site? Thanks, -- Leo Vegoda IANA Numbers Liaison From daniel.karrenberg at ripe.net Tue Feb 13 08:51:47 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 13 Feb 2007 08:51:47 +0100 Subject: [g4] Re: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: References: <45C993B0.8090704@ripe.net> Message-ID: <20070213075147.GC25491@reiftel.karrenberg.net> On 12.02 16:12, Leo Vegoda wrote: > Hi Andrew, > > On Feb 7, 2007, at 9:54 AM, Andrew de la Haye wrote: > > [...] > > >By the end of this week an additional document will be provided, > >containing open generic and very specific questions and discussion > >items. > > Was this document sent? I can't see it in the mail archive on the web > site? I am also curious about it. Unfortunately I cannot make the meeting today because I am down with a serious coughing and sneezing thing. I believe part of this doc was to be an exose around the following thoughts: - what is the service we propose ? - what is the service provided by us ? - concrete service elements - service description / draft documentation - how does one use it ? - service description / draft documentation - change/new processes at RS - change/new processes at customer - ... - what are the benefits to the membership - potental simplification and strengthening of provisioning processes - potential for secure routing protocols - potential for secure transfer of number resources - how will THAT work exactly? - ... - what are non benefits - miraculous improvement of registry data - replacement of registries - ... - what are the costs for the member - changed processes - cost of CA - and *here* only start about the "CA service" - what are the costs at the NCC - what is the expected uptake - slow / fast ? - does uptake affect usefulness benefits ? - measures to promote uptake - what are the consequences for members who do not take up the service? I'd also like to offer the following to think about: It is often implied that certification will improve the overall quality of registration data and provide a better handle on who is the user of a certain block of address space. I argue that it is more likely that this will not be the case: 1) New certificates for existing address space will be based on the current registration data. So by definition they cannot be more accurate. 2) When certificates and registration databases co-exist both systems will diverge and show different information. Is this an improvement? 3) When and if certificates supersede the registration databases for operational purposes, the incentives to maintain the registration databases will be reduced and registration databases will deteriorate. Especially the last point deserves attention. A lot of operational coordination is based on the registration databases; will this still be possible with degraded or seriously out-of-date registration databases? Are we prepared to loose the capability of direct operational coordination and to revert to a coordination model that follows peering relationships only? The registration databases also serve valid functions for other users ranging from policy makers via law-enforcement to individual Internet users. Deterioration of the databases will cause dissatisfaction and resistance from those users. How are we going to deal with that? Again apologies for not being there. Force majeure cough/sneeze Daniel From daniella at ripe.net Tue Feb 13 09:12:52 2007 From: daniella at ripe.net (=?ISO-8859-1?Q?Dani=EBlla_Coutinho?=) Date: Tue, 13 Feb 2007 09:12:52 +0100 Subject: [g4] Re: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <20070213075147.GC25491@reiftel.karrenberg.net> References: <45C993B0.8090704@ripe.net> <20070213075147.GC25491@reiftel.karrenberg.net> Message-ID: <45D17304.4080506@ripe.net> Dear All, I can inform you that the mentioned additional document has not been sent. Additional comments will be provided today during the workshop. Regards, Dani?lla Daniel Karrenberg wrote: > On 12.02 16:12, Leo Vegoda wrote: >> Hi Andrew, >> >> On Feb 7, 2007, at 9:54 AM, Andrew de la Haye wrote: >> >> [...] >> >>> By the end of this week an additional document will be provided, >>> containing open generic and very specific questions and discussion >>> items. >> Was this document sent? I can't see it in the mail archive on the web >> site? > > I am also curious about it. Unfortunately I cannot make the meeting today because > I am down with a serious coughing and sneezing thing. I believe part of this doc > was to be an exose around the following thoughts: > > - what is the service we propose ? > - what is the service provided by us ? > - concrete service elements > - service description / draft documentation > - how does one use it ? > - service description / draft documentation > - change/new processes at RS > - change/new processes at customer > - ... > > - what are the benefits to the membership > - potental simplification and strengthening of provisioning processes > - potential for secure routing protocols > - potential for secure transfer of number resources > - how will THAT work exactly? > - ... > > - what are non benefits > - miraculous improvement of registry data > - replacement of registries > - ... > > - what are the costs for the member > - changed processes > - cost of CA > - and *here* only start about the "CA service" > > - what are the costs at the NCC > > - what is the expected uptake > - slow / fast ? > - does uptake affect usefulness benefits ? > - measures to promote uptake > > - what are the consequences for members who do not take up the service? > > > > I'd also like to offer the following to think about: > > It is often implied that certification will improve the overall quality > of registration data and provide a better handle on who is the user of a > certain block of address space. I argue that it is more likely that this > will not be the case: > > 1) New certificates for existing address space will be based on the > current registration data. So by definition they cannot be more > accurate. > > 2) When certificates and registration databases co-exist both systems > will diverge and show different information. Is this an improvement? > > 3) When and if certificates supersede the registration databases for > operational purposes, the incentives to maintain the registration > databases will be reduced and registration databases will deteriorate. > > Especially the last point deserves attention. A lot of operational > coordination is based on the registration databases; will this still be > possible with degraded or seriously out-of-date registration databases? > Are we prepared to loose the capability of direct operational > coordination and to revert to a coordination model that follows peering > relationships only? > > The registration databases also serve valid functions for > other users ranging from policy makers via law-enforcement to individual > Internet users. Deterioration of the databases will cause dissatisfaction > and resistance from those users. How are we going to deal with that? > > > > Again apologies for not being there. Force majeure > > cough/sneeze > > Daniel > From henk at ripe.net Wed Feb 14 15:49:50 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Wed, 14 Feb 2007 15:49:50 +0100 Subject: [g4] Re: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <20070213075147.GC25491@reiftel.karrenberg.net> References: <45C993B0.8090704@ripe.net> <20070213075147.GC25491@reiftel.karrenberg.net> Message-ID: <45D3218E.8050603@ripe.net> Hi all, > It is often implied that certification will improve the overall quality > of registration data and provide a better handle on who is the user of a > certain block of address space. I argue that it is more likely that this > will not be the case: > > 1) New certificates for existing address space will be based on the > current registration data. So by definition they cannot be more > accurate. If we hand out certificates for all our data based on current registration data, then yes, you are right. If, OTOH, we only make certificates available to people who ask for it, then the data quality will improve, as one can ask the LIR to check the data before the certificate is handed out. > 2) When certificates and registration databases co-exist both systems > will diverge and show different information. Is this an improvement? No, it is not, but then I would not design the system such that there are two master DB's that are independently maintained. There should be one that is the master and is maintained. All other systems should pull their information from there. And all business/system analysis that we have done so far, assumes that there is one (internal) registration DB, with all resources belonging to a LIR. If there are changes, that one is updated, then the certificate is generated from that data and thus will always be consistent with our internal records. This obviously doesn't help, but nor does it have a negative impact, on DB's that people maintain themselves. > The registration databases also serve valid functions for > other users ranging from policy makers via law-enforcement to individual > Internet users. Deterioration of the databases will cause dissatisfaction > and resistance from those users. How are we going to deal with that? I think the focus will change: * It will be clear that the person who is asking another party to do something with a resource, is actually authorized to use it, thus reducing the number of incidents. * Certificates will have to be renewed. At this point, one can ask people to verify if data is still correct, and if not, correct it before the new cert is generated. (And this is something that can be automated to a large extend). Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk 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 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment." From leo.vegoda at icann.org Wed Feb 14 18:28:11 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 14 Feb 2007 18:28:11 +0100 Subject: [g4] Re: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <45D3218E.8050603@ripe.net> References: <45C993B0.8090704@ripe.net> <20070213075147.GC25491@reiftel.karrenberg.net> <45D3218E.8050603@ripe.net> Message-ID: <6838742B-3244-4962-A477-AC31D0947859@icann.org> On Feb 14, 2007, at 3:49 PM, Henk Uijterwaal wrote: [...] >> It is often implied that certification will improve the overall >> quality >> of registration data and provide a better handle on who is the >> user of a >> certain block of address space. I argue that it is more likely >> that this >> will not be the case: >> 1) New certificates for existing address space will be based on the >> current registration data. So by definition they cannot be more >> accurate. > > If we hand out certificates for all our data based on current > registration > data, then yes, you are right. If, OTOH, we only make certificates > available > to people who ask for it, then the data quality will improve, as > one can ask > the LIR to check the data before the certificate is handed out. This can be true if the process for obtaining a certificate is more onerous than ticking a box on a web page, which was a possibility briefly mentioned yesterday. Data quality can only improve by requiring regular updates or checks. If the emphasis is on quality then the process will be relatively expensive when scaled up to a situation with tens of thousands of certificates. There is probably a trade-off between near universal certification and useful contact information for most resources. >> 2) When certificates and registration databases co-exist both systems >> will diverge and show different information. Is this an improvement? > > No, it is not, but then I would not design the system such that > there are > two master DB's that are independently maintained. There should be > one > that is the master and is maintained. All other systems should pull > their information from there. The data presumably has to come from the resource holders. Getting then to confirm or update the data on a regular basis sounds like a challenging task. Making sure that the person providing the update knows the correct contact information and can supply it might also be difficult... [...] > * Certificates will have to be renewed. At this point, one can ask > people to > verify if data is still correct, and if not, correct it before > the new cert > is generated. (And this is something that can be automated to a > large > extend). ... as the person renewing the certificate in many organisations is likely be a payments clerk and not involved in network operations. Regards, -- Leo Vegoda IANA Numbers Liaison From henk at ripe.net Thu Feb 15 08:09:58 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 15 Feb 2007 08:09:58 +0100 Subject: [g4] Re: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <6838742B-3244-4962-A477-AC31D0947859@icann.org> References: <45C993B0.8090704@ripe.net> <20070213075147.GC25491@reiftel.karrenberg.net> <45D3218E.8050603@ripe.net> <6838742B-3244-4962-A477-AC31D0947859@icann.org> Message-ID: <45D40746.4010206@ripe.net> Leo, others, (Moved the discussion to the ca-tf list only.) > Data quality can only improve by requiring regular updates or checks. I think this is the key point: right now, there is nothing that shows people on a more or less regular basis what their data is. In a certification scheme, people will have to renew certificates and thus see their data at least once a year. And most people, when shown a list of data, will point out errors they see. This will, of course, not make the data perfect, but it will improve its quality. > The data presumably has to come from the resource holders. I'd think (at least some of it) comes from the RIRs. How else can you avoid that people certify resources for which they are not responsible? > ... as the person renewing the certificate in many organisations is > likely be a payments clerk and not involved in network operations. I'm not sure about that. First of all, this is a technical operation. Besides getting the certificate, you will also have to install it in your CA. Also, the certificate may cover a set different from everything one has. In both cases, I'd rather have this done by a person involved in network operations, than by a person involved in finance. Second, I think that the payments clerk will at least be aware of the current name of the organization, its postal address, phone number and the name of the person/department running the network. If he only corrects those, then we will already see an improvement. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk 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 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment." From leo.vegoda at icann.org Thu Feb 15 10:07:38 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 15 Feb 2007 10:07:38 +0100 Subject: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <45D40746.4010206@ripe.net> References: <45C993B0.8090704@ripe.net> <20070213075147.GC25491@reiftel.karrenberg.net> <45D3218E.8050603@ripe.net> <6838742B-3244-4962-A477-AC31D0947859@icann.org> <45D40746.4010206@ripe.net> Message-ID: <736E4CE3-1F5A-435C-A0C7-E1AB2A1D33BE@icann.org> On Feb 15, 2007, at 8:09 AM, Henk Uijterwaal wrote: [...] >> Data quality can only improve by requiring regular updates or checks. > > I think this is the key point: right now, there is nothing that shows > people on a more or less regular basis what their data is. In a > certification scheme, people will have to renew certificates and thus > see their data at least once a year. And most people, when shown a > list > of data, will point out errors they see. > > This will, of course, not make the data perfect, but it will improve > its quality. > >> The data presumably has to come from the resource holders. > > I'd think (at least some of it) comes from the RIRs. How else can you > avoid that people certify resources for which they are not > responsible? The RIR can be authoritative about which resources are registered to an organisation. Attempts to change that can be flagged for further review. RIRs cannot know whether a change in the other contact information is correct, though. The registrant must know best for anything other than registrant name. And this is where the problem lies. If the RIPE NCC provides a CA outsourcing service then it significantly reduces the need for network people to be involved in the certificate renewal. But by reducing this need it risks a deterioration in contact information when registrants' internal communications are less than exemplary. Introducing certification of resources might lead to a better idea of the legal identity of resource holders but less useful contact information for them. Regards, Leo From robert at ripe.net Thu Feb 15 10:31:26 2007 From: robert at ripe.net (=?ISO-8859-1?Q?R=F3bert_Kisteleki?=) Date: Thu, 15 Feb 2007 10:31:26 +0100 Subject: [ca-tf] Draft pre-read document for the CA-TF workshop of 13 February In-Reply-To: <736E4CE3-1F5A-435C-A0C7-E1AB2A1D33BE@icann.org> References: <45C993B0.8090704@ripe.net> <20070213075147.GC25491@reiftel.karrenberg.net> <45D3218E.8050603@ripe.net> <6838742B-3244-4962-A477-AC31D0947859@icann.org> <45D40746.4010206@ripe.net> <736E4CE3-1F5A-435C-A0C7-E1AB2A1D33BE@icann.org> Message-ID: <45D4286E.1030507@ripe.net> > And this is where the problem lies. If the RIPE NCC provides a CA > outsourcing service then it significantly reduces the need for network > people to be involved in the certificate renewal. But by reducing this > need it risks a deterioration in contact information when registrants' > internal communications are less than exemplary. During the renewal process, we can also define a step between acknowledgment of payment and the actual renewal of the certificate, where we ask the LIR to confirm contact information details. This could be coupled with other steps, like "check the bill and the contact information attached, and pay if okay", but it might be better to separate the two. Anyway, the idea is that _before_ renewal, we ask for confirmation from the LIR, which IMHO does not slow down the process significantly. Cheers, Robert From andrew at ripe.net Fri Feb 23 16:29:04 2007 From: andrew at ripe.net (Andrew de la Haye) Date: Fri, 23 Feb 2007 16:29:04 +0100 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting Message-ID: <45DF0840.9080509@ripe.net> Dear all, attached you will find the write-up of the CA-TF kick-off meeting of last week. As discussed, we will group areas and facilitate the discussion of these areas (one-by-one) on the mailing list. I would like to propose a tentative date for an additional Task Force meeting, to enable the Task Force to meet face tot face and get feedback on the items to be addressed during Ripe 54 in May. The proposed date is Tuesday 17 April. If you have any questions, please don't hesitate to contact me. Kind regards, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: tf-meeting1-minutes-1.3.doc Type: application/msword Size: 65024 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20070223/a4c0707f/attachment.doc From henk at ripe.net Tue Feb 27 12:43:49 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 27 Feb 2007 12:43:49 +0100 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <45DF0840.9080509@ripe.net> References: <45DF0840.9080509@ripe.net> Message-ID: <45E41975.5080804@ripe.net> Dear All, > As discussed, we will group areas and facilitate the discussion of these > areas (one-by-one) on the mailing list. To get started: It would be good if everybody could read these minutes and confirm (or deny) that they are a fair representation of what was said during the meeting. If we forgot anything essential or misquoted you, please let us know by Friday, March 9, 12:00 cet. It looks like we then have the following topics with questions and open issues: a) Checks on customers seeking certification b) Revocation of certs and resources c) How to generate a critical mass of users d) End users and PI space e) Resource Transfers f) Certificate repository g) Policy issues h) Open questions i) Anything that we forgot. These are 9 areas. The TF has to be ready by RIPE55 (October), or in 5 months time. If we substract a bit of time to prepare a report, this gives us approximately 2-3 weeks per topic. I suggests, for the lack of a better idea, to address these topics in this order and give ourselves 2 weeks/topic (and a bit more during the summer months with people vacationing). Does this sound reasonable? Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk 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 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment." From dol at cryptocom.ru Tue Feb 27 14:02:38 2007 From: dol at cryptocom.ru (Vasily Dolmatov) Date: Tue, 27 Feb 2007 16:02:38 +0300 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <45E41975.5080804@ripe.net> References: <45DF0840.9080509@ripe.net> <45E41975.5080804@ripe.net> Message-ID: <001901c75a6f$8e6b60e0$f111330a@2265> > > It looks like we then have the following topics with > questions and open issues: It seems that for reasonable discussion of mentioned below topics we need first of all to determine goals which we wish to achieve from certification implementation, both as short-term goals as well as long-term goals. Setting of different goals (and even different order of their achievement) can change drastically meaning of statements below and definitely will change the contents of these statements. So, I propose to start from setting goals, I hope one 2-week "timeslot" will be enough for that, but it is necessary to determine it, agree upon it and _write_it_down_ for having possibility to reread it during discussion process. Otherwise we can fall in the bottomless pit of endless discussing of practical steps having in mind different pictures of the world. ;) > > a) Checks on customers seeking certification > b) Revocation of certs and resources > c) How to generate a critical mass of users > d) End users and PI space > e) Resource Transfers > f) Certificate repository > g) Policy issues > h) Open questions > i) Anything that we forgot. > > These are 9 areas. The TF has to be ready by RIPE55 > (October), or in 5 months time. If we substract a bit of > time to prepare a report, this gives us approximately 2-3 > weeks per topic. > > I suggests, for the lack of a better idea, to address these > topics in this order and give ourselves 2 weeks/topic (and a > bit more during the summer months with people vacationing). > Does this sound reasonable? > > Henk > > -- > -------------------------------------------------------------- > ---------------- > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre > http://www.amsterdamned.org/~henk > 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 > -------------------------------------------------------------- > ---------------- > > # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" > # Witness: "Thank you. If I weren't under oath, I'd return > the compliment." > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3105 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20070227/f7c2633e/attachment.bin From martin at 2connectbahrain.com Tue Feb 27 19:32:50 2007 From: martin at 2connectbahrain.com (Martin Papik) Date: Tue, 27 Feb 2007 21:32:50 +0300 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <001901c75a6f$8e6b60e0$f111330a@2265> Message-ID: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> I totally agree, we need clear goals or we're doomed. Some of the goals are listed below (in random order). Please add anything I left out. And not all need to be a part of this project. Right now we need to clarify what this project will be about, what we're going to put a chunk of our lives into. The actual goals: * Better accuracy of data regarding IP address allocations * Legal accountability of IP address usage * Increased routing security Supportive goals: * design/build infrastructure, both technical (CA, protocols, etc) and non technical (policies, procedures) to support the certification process * document policies, procedures, typical examples (small ISP, large telco, multinational company, etc.) * make it a viable option for everybody * make it a desired choice for most * educate people why they want it (even they've never heard of it, especially) * decide on data validity hierarchy (e.g. WHOIS supplemented by certificates or vice versa) * do a case study of what segment of resource holders would cooperate, which would not and why (for both answers if possible) * design the transition between the current state and the desired end result * consider technical implications and requirements (data availability, fault tolerance, data access) * consider non-technical implications and requirements (legal responsibility, disputes, penalties, changes to existing procedures, question of IP address ownership/sale) * eat a lot of good lunches and dinners in good company, have fun and be merry Martin Martin Papik 2Connect W.L.L. 12th Floor, NBB Tower Tel: +973-17-500-110 Fax: +973-17-500-109 Mobile: +973-39-766-963 > -----Original Message----- > From: ca-tf-admin at ripe.net [mailto:ca-tf-admin at ripe.net] On Behalf Of > Vasily Dolmatov > Sent: Tuesday, February 27, 2007 4:03 PM > To: 'Henk Uijterwaal'; 'Andrew de la Haye' > Cc: ca-tf at ripe.net > Subject: RE: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting > > > > > > > It looks like we then have the following topics with > > questions and open issues: > It seems that for reasonable discussion of mentioned below topics we need > first of all to determine goals which we wish to achieve from > certification > implementation, both as short-term goals as well as long-term goals. > Setting of different goals (and even different order of their achievement) > can change drastically meaning of statements below and definitely will > change the contents of these statements. > > So, I propose to start from setting goals, I hope one 2-week "timeslot" > will > be enough for that, but it is necessary to determine it, agree upon it and > _write_it_down_ for having possibility to reread it during discussion > process. > Otherwise we can fall in the bottomless pit of endless discussing of > practical steps having in mind different pictures of the world. ;) > > > > > a) Checks on customers seeking certification > > b) Revocation of certs and resources > > c) How to generate a critical mass of users > > d) End users and PI space > > e) Resource Transfers > > f) Certificate repository > > g) Policy issues > > h) Open questions > > i) Anything that we forgot. > > > > These are 9 areas. The TF has to be ready by RIPE55 > > (October), or in 5 months time. If we substract a bit of > > time to prepare a report, this gives us approximately 2-3 > > weeks per topic. > > > > I suggests, for the lack of a better idea, to address these > > topics in this order and give ourselves 2 weeks/topic (and a > > bit more during the summer months with people vacationing). > > Does this sound reasonable? > > > > Henk > > > > -- > > -------------------------------------------------------------- > > ---------------- > > Henk Uijterwaal Email: > > henk.uijterwaal(at)ripe.net > > RIPE Network Coordination Centre > > http://www.amsterdamned.org/~henk > > 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 > > -------------------------------------------------------------- > > ---------------- > > > > # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" > > # Witness: "Thank you. If I weren't under oath, I'd return > > the compliment." > > > > From leo.vegoda at icann.org Wed Feb 28 04:13:18 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 28 Feb 2007 11:13:18 +0800 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> Message-ID: On Feb 28, 2007, at 2:32 AM, Martin Papik wrote: > I totally agree, we need clear goals or we're doomed. Some of the > goals are listed below (in random order). Please add anything I > left out. And not all need to be a part of this project. Right now > we need to clarify what this project will be about, what we're > going to put a chunk of our lives into. > > The actual goals: > > * Better accuracy of data regarding IP address allocations > * Legal accountability of IP address usage > * Increased routing security The system in place now reports the last known information held for the 'registrant'. That doesn't really scale to an Internet with tens of thousands of ASs. It is also unlikely to provide the legal certainty needed by resource holders in an age of scarcity. If we move to a certification system it needs to certify that the certificate holder has a right to use the resources that are certified. Whoever controls the certificate needs to be able use it to assure other people that they can authorise the use of the resources and the transfer of the resources. I think that means that accurate registration data, legal accountability and better routing security should follow automatically from a system with a hard certification of a right to use resources. > Supportive goals: > > * design/build infrastructure, both technical (CA, protocols, etc) > and non technical (policies, procedures) to support the > certification process > * document policies, procedures, typical examples (small ISP, large > telco, multinational company, etc.) > * make it a viable option for everybody > * make it a desired choice for most > * educate people why they want it (even they've never heard of it, > especially) > * decide on data validity hierarchy (e.g. WHOIS supplemented by > certificates or vice versa) > * do a case study of what segment of resource holders would > cooperate, which would not and why (for both answers if possible) > * design the transition between the current state and the desired > end result > * consider technical implications and requirements (data > availability, fault tolerance, data access) > * consider non-technical implications and requirements (legal > responsibility, disputes, penalties, changes to existing > procedures, question of IP address ownership/sale) > * eat a lot of good lunches and dinners in good company, have fun > and be merry These are all god goals. Regards, -- Leo Vegoda IANA Numbers Liaison From dol at cryptocom.ru Wed Feb 28 10:58:22 2007 From: dol at cryptocom.ru (Vasily Dolmatov) Date: Wed, 28 Feb 2007 12:58:22 +0300 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> Message-ID: <001401c75b1e$fb7231a0$f111330a@2265> > -----Original Message----- > From: ca-tf-admin at ripe.net [mailto:ca-tf-admin at ripe.net] On > Behalf Of Leo Vegoda > Sent: Wednesday, February 28, 2007 6:13 AM > To: Martin Papik > Cc: 'Vasily Dolmatov'; 'Henk Uijterwaal'; 'Andrew de la > Haye'; ca-tf at ripe.net > Subject: Re: [ca-tf] Next steps & Write-up of the CA-TF > kick-off meeting > > On Feb 28, 2007, at 2:32 AM, Martin Papik wrote: > > > I totally agree, we need clear goals or we're doomed. Some of the > > goals are listed below (in random order). Please add > anything I left > > out. And not all need to be a part of this project. Right > now we need > > to clarify what this project will be about, what we're > going to put a > > chunk of our lives into. > > > > The actual goals: > > > > * Better accuracy of data regarding IP address allocations > > * Legal accountability of IP address usage > > * Increased routing security > > The system in place now reports the last known information > held for the 'registrant'. That doesn't really scale to an > Internet with tens of thousands of ASs. It is also unlikely > to provide the legal certainty needed by resource holders in > an age of scarcity. If we move to a certification system it > needs to certify that the certificate holder has a right to > use the resources that are certified. Whoever controls the > certificate needs to be able use it to assure other people > that they can authorise the use of the resources and the > transfer of the resources. > > I think that means that accurate registration data, legal > accountability and better routing security should follow > automatically from a system with a hard certification of a > right to use resources. > As it was already mentioned during the meeting, different goals require different designs of certification system. It is correct that if "maximum" system is made, then all goals will be reached. >From the other side, "system with a hard certification" is quite complicated for design and implementation even inside one well managed enterprise, and I consider such system as impossible in the RIPE (and any other RIR) situation. "System" - means not only CA, whish issue certificates, but a lot of measures and procedures which are targeted to ensure trust of issued certificates. Failure to implement even one from that lot of procedures immediatedly waives any legal significance of issued certificate. That was the reason why I asked about the goals of the system. If it would be agreed that primary goal is to implement "hard certification" I immediatedly become very pessimistic about perspectives of this project. I consider this goal unreachable in the current situation and in the nearest perspective, this could be stated as a "strategic goal" indicating the movement of RIPE NCC towards global digital society, but it cannot be set as a short-term (1-2 years) or long-term (3-5 years) goals. I enumerate just a few implications of "hard certification system" which we are not ready to deal with in the current state of affairs: In "hard certification system" - certificate can be issued only to person (not to enterprise as a whole), so database of responsible staff of all LIRs should be maintained - certificate cannot be issued virtually (responsible person must meet requestor "eye-to-eye" and check his/her identity against set of paper personal IDs before issuing certificate) - certificate can not be transferred to other person - private keys must be created and handled in manner which excludes possibility of their duplicating or misuse (storing them in the file"with passphrase protection" is not even considered) - certificates should be immediatedly revoked when given person leaves given LIR, that means procedures of resigning LIR objects There are a lot of other implications, and as I think it is impossible and unwise to try to implement now "hard certification system" in the RIPE community. As it was said above, not following the even the only one of known rules of building of "hard certification systems" ruins trust in this system completely and this system become _an_imitation_ of "hard security system". I doubt that it is the goal of this project. ;) Certificates are an element of "system of trust" (crucial one, no doubt), the "system of trust" is the means of making "something". Let us understand clearly _which_ "something" we want to make and what kind of "system of trust" we need in order to achieve this "something". Let me repeat, I consider that setting the creation of "hard certification system" as current goal (or even as a second-stage goal) is unrealistic, because of: - srtucture of "hard certification system" will immediatedly come into conflict with current srtucture and principles of operation of RIPE community - releasing some principles of "hard certification system" in order to make it compatible with structure and procedures of RIPE community creates an _imitation_ of "hard certification system" which will claim that trust and security is maintained, but there will be _no_ trust and _no_ security in this system (being exact, the level of trust and security will remain the same as before, but a lot of efforts will be spent and lot of implications will be imposed on the participants of the system) For instance, if it will be possible for LIR to get certificates, using current web-portal and current authorisation scheme - it will never be "hard certification system" and these certificates will never have any legal meaning. I want to state separately, that I consider that implementing of "hard certification system" inside RIPE NCC for increasing trust to everything which is sourced by RIPE NCC is quite a reasonable task and it is _real_ to implement. It is possible to design and properly operate such a system with hard certification for RIPE NCC staff and RIPE NCC operations. First possible outcome of that could be the signing of route objects in RIPE NCC database by RIPE NCC, thus eliminating possible threat of "phishing" of whois.ripe.net in order to desorganize routing. This will be the real increase in trust and security, which seems reasonable as a first step. (TBC) dol@ > > > Supportive goals: > > > > * design/build infrastructure, both technical (CA, > protocols, etc) and > > non technical (policies, procedures) to support the certification > > process > > * document policies, procedures, typical examples (small ISP, large > > telco, multinational company, etc.) > > * make it a viable option for everybody > > * make it a desired choice for most > > * educate people why they want it (even they've never heard of it, > > especially) > > * decide on data validity hierarchy (e.g. WHOIS supplemented by > > certificates or vice versa) > > * do a case study of what segment of resource holders would > cooperate, > > which would not and why (for both answers if possible) > > * design the transition between the current state and the > desired end > > result > > * consider technical implications and requirements (data > availability, > > fault tolerance, data access) > > * consider non-technical implications and requirements (legal > > responsibility, disputes, penalties, changes to existing > procedures, > > question of IP address ownership/sale) > > * eat a lot of good lunches and dinners in good company, > have fun and > > be merry > > These are all god goals. > > Regards, > > -- > Leo Vegoda > IANA Numbers Liaison > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3105 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20070228/37596015/attachment.bin From leo.vegoda at icann.org Wed Feb 28 11:23:18 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 28 Feb 2007 18:23:18 +0800 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <001401c75b1e$fb7231a0$f111330a@2265> References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> <001401c75b1e$fb7231a0$f111330a@2265> Message-ID: Hi Vasily, On Feb 28, 2007, at 5:58 PM, Vasily Dolmatov wrote: [...] > For instance, if it will be possible for LIR to get certificates, > using > current web-portal and current authorisation scheme - it will never > be "hard > certification system" and these certificates will never have any legal > meaning. Can you please expand on this. I suspect that using the LIR Portal - or something based on it - would be an excellent way of getting widespread take-up. Thanks, -- Leo Vegoda IANA Numbers Liaison From dol at cryptocom.ru Wed Feb 28 12:49:38 2007 From: dol at cryptocom.ru (Vasily Dolmatov) Date: Wed, 28 Feb 2007 14:49:38 +0300 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> <001401c75b1e$fb7231a0$f111330a@2265> Message-ID: <002d01c75b2e$86989bc0$f111330a@2265> > -----Original Message----- > From: Leo Vegoda [mailto:leo.vegoda at icann.org] > Sent: Wednesday, February 28, 2007 1:23 PM > To: Vasily Dolmatov > Cc: 'Martin Papik'; 'Henk Uijterwaal'; 'Andrew de la Haye'; > ca-tf at ripe.net > Subject: Re: [ca-tf] Next steps & Write-up of the CA-TF > kick-off meeting > > Hi Vasily, > > On Feb 28, 2007, at 5:58 PM, Vasily Dolmatov wrote: > > [...] > > > For instance, if it will be possible for LIR to get certificates, > > using current web-portal and current authorisation scheme - it will > > never be "hard certification system" and these certificates > will never > > have any legal meaning. > > Can you please expand on this. I suspect that using the LIR > Portal - or something based on it - would be an excellent way > of getting widespread take-up. > "widespread take-up" - yes. "legal meaning" - no. It was explained in the skipped text. ;) In brief: There is no way to _ensure_ that certificate was taken by proper person. There is crucial difference between "Leo Vegoda with valid passport in hand" and "someone who connected to the Portal using two text strings, which some time ago were sent by e-mail to someone who wrote he was Leo Vegoda". So, certificate generated in the first case can legally represent Leo Vegoda (provided another lot of conditions were met), certificate generated in the second case can represent _nothing_ and _noone_. It will be issued and transferred to _unknown_person_ who happened to posess knowlegde of pair of text strings in given moment of time. No claims concerning following actions using this certificate can be considered either legally or logically. The trick is that "security is a chain" and security is so hard as hard is the weakest link in this chain. Web authentication via login/password pair is _weak_. Period. It can be (and is) enough for tasks performed with LIR portal now, but this procedure has no trust in it, so no secure procedure can inherit this trust from it. Because of absence of this trust. Nothing to inherit. That is the reason why I continue to ask about GOALS. If we have a goal to implement legally meaningful system - we cannot use LIR Portal for start of it. If we have no such goal - we can use LIR Portal, but then the question arise again: "What are we implementing certificates for?" Starting from LIR Portal they cannot give us more trust (see above), as for security - it is necessary to deduce which procedures will become more secure with certificates (which were issued with _same_level_ of trust as in the current system) as compared with current situation when information is circulating without using of certificates. There is basic item in information security: "threats model" One need to start securing information system from understanding which threats it is opposed to, which threats are significant and should be defended from and which threats are unlikely or not so dangerous so can be ignored. After that it becomes possible to design security system and implement various security technologies. Any security system design is a tradeoff between security and usability and one should clearly see and understand what threats were ignored and why. ;) As I can see now, when struggling with threats - that someone can claim that some operations with resources which were assigned to him were performed without his knowledge and against his will and he consider RIPE NCC legally responsible for the consequencies and possible losses - that someone can decline responsibility for some evil operations which were performed from IP-space assigned to him - that there will be resources which assigned to someone with whom there is no possibility to communicate by RIPE NCC - (which are other?) One have no or little help from implementation of "hard certificate system" First threat is eliminated with proper authentication procedure when making operations (there are a bunch of authentication methods and certificates are only one of them and "hard certificates" are the very special branch of certificates) and inserting proper clauses in the agreement between RIPE NCC and LIR in order to avoid possible suing. Second threat has really no connection with certificate problem at all... Assigning some IP space to a LIR in order to be further used by clients of this LIR gives no legal possibilities to force LIR to make something, using certificates or not. ;) This threat should be struggled with by other means, maybe by cooperating LIRs around some kind of CERT or something. Third threat is again not connected directly with certificate usage, implementation of certificates maybe a good occasion to clean up "dead bodies" from the database, but that could be done without certificates as well, another good occasion is prolongation of contract with LIR, which takes place on yearly basis. Either it is said that "there will be no certificate to those whose contact data is invalid", or "there will be no contract prolongation to those..." Certificates are just the cause for action which has no direct connection with certificates. If there are other threats which could be addressed with implementation of "hard certificate system" please, lay them on the table for considering. ;) dol@ > Thanks, > > -- > Leo Vegoda > IANA Numbers Liaison > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3105 bytes Desc: not available Url : https://www.ripe.net/ripe/mail/archives/ca-tf/attachments/20070228/93157e7b/attachment.bin