From leo.vegoda at icann.org Thu Mar 1 05:34:24 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 1 Mar 2007 12:34:24 +0800 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <002d01c75b2e$86989bc0$f111330a@2265> References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> <001401c75b1e$fb7231a0$f111330a@2265> <002d01c75b2e$86989bc0$f111330a@2265> Message-ID: On Feb 28, 2007, at 7:49 PM, Vasily Dolmatov wrote: [...] > 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. In the past I have been told that the RIRs do not intend to certify identity, only control of the resources. The analogy I was given was that of a bearer bond: if you hold the bond you can cash it in. [...] > 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 Isn't this already covered by article 7 of the RIPE NCC's Standard Terms & Conditions? > - that someone can decline responsibility for some evil operations > which > were performed from IP-space assigned to him I'm sure they can always do that, anyway. Isn't it up to the court system to determine facts in an "evil operations" case? > - that there will be resources which assigned to someone with whom > there is > no possibility to communicate by RIPE NCC So the certificate is never issued or expired? I don't understand how this is a threat. Can you expand on it? I don't understand how the threats you have described are likely to stop the RIPE NCC offering a service where the holder of a certificate (whoever that is) controls the resource. And more importantly, I don't see why not certifying identity should stop the RIPE NCC offering a service that allows the certificate holder to assure other people that they can authorise the use of the resources and the transfer of the resources. Regards, -- Leo Vegoda IANA Numbers Liaison From andrei at ripe.net Thu Mar 1 08:13:52 2007 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 01 Mar 2007 08:13:52 +0100 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <002d01c75b2e$86989bc0$f111330a@2265> References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> <001401c75b1e$fb7231a0$f111330a@2265> <002d01c75b2e$86989bc0$f111330a@2265> Message-ID: <45E67D30.4060407@ripe.net> Vasily, others, Vasily Dolmatov wrote: [...] > 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. > I understand that you probably used an identity certificate an an example only, but perhaps we need to ensure we are on the same page WRT what the resource certificates are certifying. Current thinking is that those certificates only state that - resources listed in the extension have been allocated (and that can be validated) - the holder of the private key corresponding to the public key in the certificate has right to use the resources. This is explained in more detail in the Certificate Policy that is being discussed in the IETF: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-01.txt In particular this document states: "1.4.1. Appropriate certificate uses The certificates issued under this hierarchy are for authorization in support of validation of claims of current holdings of address space and/or AS numbers, e.g., for routing security. With regard to routing security, an initial goal of this PKI is to allow the holder of a set of address blocks to be able to declare, in a secure fashion, the AS number of each entity that is authorized to originate a route to these addresses, including the context of ISP proxy aggregation. Additional uses of the PKI, consistent with the basic goal cited above, are also permitted under this policy. Some of the certificates that may be issued under this hierarchy could be used to support operation of this infrastructure, e.g., access control for the repository system. Such uses also are permitted under this policy. " Does this help in defining the goals? Regards, Andrei [...] From robert at ripe.net Thu Mar 1 12:06:49 2007 From: robert at ripe.net (=?ISO-8859-1?Q?R=F3bert_Kisteleki?=) Date: Thu, 01 Mar 2007 12:06:49 +0100 Subject: [ca-tf] [Fwd: [Sidr] I-D ACTION:draft-ietf-sidr-arch-00.txt] Message-ID: <45E6B3C9.9050705@ripe.net> Dear All, I'd like draw attention to the IETF SIDR WG for all who does not follow it: the mailing list is currently "flooded" with certification relevant drafts: - general infrastructure (see below) - resource certificate profile - general certificate policy - certificate policy for ISPs/LIRs - ROA format Lots and lots to read, I know, but these will be the standards we need to follow, so please look at them if you can. Regards, Robert -------- Original Message -------- Subject: [Sidr] I-D ACTION:draft-ietf-sidr-arch-00.txt Date: Wed, 28 Feb 2007 18:50:02 -0500 From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org CC: sidr at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : An Infrastructure to Support Secure Internet Routing Author(s) : R. Barnes, S. Kent Filename : draft-ietf-sidr-arch-00.txt Pages : 16 Date : 2007-2-28 This document describes an architecture for an infrastructure to support secure Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; certificates from this PKI are used to verify signed objects that authorize autonomous systems to originate routes for specified IP address prefixes. The data objects that comprise the PKI, as well as other signed objects necessary for secure routing, are stored and disseminated through a distributed repository system. This document also describes at a high level how this architecture can be used to add security features to common operations such as IP address space allocation and route filter construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From dol at cryptocom.ru Thu Mar 1 13:46:25 2007 From: dol at cryptocom.ru (Vasily Dolmatov) Date: Thu, 1 Mar 2007 15:46:25 +0300 Subject: [ca-tf] Next steps & Write-up of the CA-TF kick-off meeting In-Reply-To: <45E67D30.4060407@ripe.net> References: <20070227183252.A13C17A4ED@mail1.2connectbahrain.com> <001401c75b1e$fb7231a0$f111330a@2265> <002d01c75b2e$86989bc0$f111330a@2265> <45E67D30.4060407@ripe.net> Message-ID: <005801c75bff$9f8414d0$f111330a@2265> > > Current thinking is that those certificates only state that > - resources listed in the extension have been allocated (and > that can be validated > - the holder of the private key corresponding to the public > key in the certificate has right to use the resources. > > This is explained in more detail in the Certificate Policy > that is being discussed in the IETF: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-01.txt > > In particular this document states: > > "1.4.1. Appropriate certificate uses > > The certificates issued under this hierarchy are for authorization > in support of validation of claims of current holdings of address > space and/or AS numbers, e.g., for routing security. With regard to > routing security, an initial goal of this PKI is to allow > the holder > of a set of address blocks to be able to declare, in a secure > fashion, the AS number of each entity that is authorized to > originate a route to these addresses, including the context of ISP > proxy aggregation. Additional uses of the PKI, consistent with the > basic goal cited above, are also permitted under this policy. > > Some of the certificates that may be issued under this hierarchy > could be used to support operation of this infrastructure, e.g., > access control for the repository system. Such uses also are > permitted under this policy. " > > Does this help in defining the goals? Yes. This definitely leaves out of the scope of this project two words "legal" and" hard", which are impossible to implement in the current state of system. Very well. Let us turn to these two points outlined above. I would like to look at current state of affairs with routing security: Now, we have RIPE NCC database, containing routing objects, which can be inserted or edited by LIRs in accordance with established hierarchy of database mantainers. Someone in the network, who is the holder of password of the correspondent mantainer can perform some operations with routing objects. Compare: Someone in the network, who is "the holder of private key corresponding to the public key in the certificate has right to use the resources" Someone in the network, who is the holder of password of the correspondent mantainer can perform some operations with resource objects, which are allocated to this mantainer. Compare: Someone in the network, who is .... have "resources listed in the extension have been allocated" What are the threats in the current procedures which are adressed by PKI implementation and will be eliminated with it? What are security weaknesses in the current procedures and why PKI will make them performed in more "secure fashion"? I cannot see any added security in PKI-based scheme if mantainers will be changed with certificates. Please, show it to me (provided no "hard certificate system" will be set up and and provided seed of certificates will be made through current LIR portal). I think that we can talk about "establishing PKI now in order to have means for increasing security in the future (in 3-5 years), when procedures will be changed appropriately". Either I cannot note something obvious, please, enlighten me. dol@ > > -------------- 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/20070301/06b72acb/attachment.bin From henk at ripe.net Thu Mar 1 15:53:30 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 01 Mar 2007 15:53:30 +0100 Subject: [ca-tf] Prototype Certification System Available Message-ID: <45E6E8EA.6000105@ripe.net> Dear Task Force Members, According to today's milestone of the certification project, we invite you to start testing our prototype certificate services. You'll find all the necessary information (documentation, software packages, essential bits) at the certificate server's homepage: http://ca-trial.ripe.net/ We ask you to direct all certification related communication (technical questions, subscribing to service, requests for certificates, etc.) to this mailing list. We will make sure they reach the appropriate staff members inside RIPE NCC. Regards, Robert Kisteleki & Henk Uijterwaal -- ------------------------------------------------------------------------------ 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 henk at ripe.net Fri Mar 9 15:17:50 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Fri, 09 Mar 2007 15:17:50 +0100 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: <45F16C8E.30301@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. Just to close this topic: I didn't receive any comments on the minutes, so I propose to declare them final. > > It looks like we then have the following topics with questions and open > issues: From the discussion, I think we should take a step back and first look at the goals of the effort. See next mail. Henk > > 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 henk at ripe.net Fri Mar 9 15:53:04 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Fri, 09 Mar 2007 15:53:04 +0100 Subject: [ca-tf] Goals of Certification Effort Message-ID: <45F174D0.3080202@ripe.net> Dear All, I think we first have to agree on the goals of this effort. Martin (I think) nicely summarized the goals in one of his earlier emails. Slightly edited, this comes down to: Main goals: 1. Better accuracy of data regarding IP and AS allocations. 2. Accountability of IP/AS usage 3. Support for routing security protocols. Supportive goals: 1. Design/build infrastructure, both technical (CA, protocols, etc) and non technical (policies, procedures) to support the certification process 2. Document policies, procedures, typical examples (small ISP, large telco, multinational company, etc.) 3. Make it a viable option for everybody 4. Make it a desired choice for most 5. Educate people why they want it (even they've never heard of it, especially) 6. Decide on data validity hierarchy (e.g. WHOIS supplemented by certificates or vice versa) 7. Do a case study of what segment of resource holders would cooperate, which would not and why (for both answers if possible) 8. Design the transition between the current state and the desired end result 9. Consider technical implications and requirements (data availability, fault tolerance, data access) A. Consider non-technical implications and requirements (legal responsibility, disputes, penalties, changes to existing procedures, question of IP address ownership/sale) B. Eat a lot of good lunches and dinners in good company, have fun and be merry Question: do we agree on these goals, is there something that has to be added or removed. Note that we do not (necessarily) reach all the goals at the same time or at the first try, but we should keep in mind that we want to reach them all eventually. Please comment on this in the next 2 weeks (now=March 24). Have a nice weekend, 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 Sun Mar 11 08:59:05 2007 From: dol at cryptocom.ru (Vasily Dolmatov) Date: Sun, 11 Mar 2007 10:59:05 +0300 Subject: [ca-tf] FW: Message-ID: <002601c763b3$24079140$f111330a@2265> > -----Original Message----- > From: Basil Dolmatov [mailto:dol at eye.cplire.ru] > Sent: Sunday, March 11, 2007 10:58 AM > To: dol at cryptocom.ru > Subject: > > -----BEGIN CERTIFICATE----- > MIIDhDCCAu2gAwIBAgIJAMpzDQBzzZNdMA0GCSqGSIb3DQEBBAUAMIGJMQswCQYD > VQQGEwJSVTEPMA0GA1UECBMGTW9zY293MQ8wDQYDVQQHEwZNb3Njb3cxEDAOBgNV > BAoTB0lSRSBSQVMxDTALBgNVBAsTBENJQ04xFzAVBgNVBAMTDkJhc2lsIERvbG1h > dG92MR4wHAYJKoZIhvcNAQkBFg9kb2xAcmVlZGNhdC5uZXQwHhcNMDcwMzExMDc1 > NjIyWhcNMTcwMzA4MDc1NjIyWjCBiTELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1v > c2NvdzEPMA0GA1UEBxMGTW9zY293MRAwDgYDVQQKEwdJUkUgUkFTMQ0wCwYDVQQL > EwRDSUNOMRcwFQYDVQQDEw5CYXNpbCBEb2xtYXRvdjEeMBwGCSqGSIb3DQEJARYP > ZG9sQHJlZWRjYXQubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDD1+7A > yu0TORiKELCHW5OprW8m1E+k+4ioe22Wg3FYxKbwnNTRYbP4xC/dk0XXDIjNIfbZ > 0Gk4seNE7jE0pvwuau4eHWXF4UekGgNMAw7iLE8v6An0DpR4wujNqGaUPMK7q74a > C5JhVZ42V3k+3cLmgywnoLXgpVPhClZ6/SleCQIDAQABo4HxMIHuMB0GA1UdDgQW > BBRMthQSU8nkES1MD+6DJ7zplasfODCBvgYDVR0jBIG2MIGzgBRMthQSU8nkES1M > D+6DJ7zplasfOKGBj6SBjDCBiTELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1vc2Nv > dzEPMA0GA1UEBxMGTW9zY293MRAwDgYDVQQKEwdJUkUgUkFTMQ0wCwYDVQQLEwRD > SUNOMRcwFQYDVQQDEw5CYXNpbCBEb2xtYXRvdjEeMBwGCSqGSIb3DQEJARYPZG9s > QHJlZWRjYXQubmV0ggkAynMNAHPNk10wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B > AQQFAAOBgQC/Y1MhbtYqCEknrlYc0UvUxxUfrs/7Naev5WXI6qTSwJOl8dyfJZax > IhKjoUkseA/sDD9L+NjkMnnTxHpkzzfGvVdfzyAs6zvwa0mf4irrRmVAblwYtQtw > UbarenmhAhsrOU9njzlUqodSq5L9E+dIXuOkGJwKo5a1eGCxM4hfFQ== > -----END CERTIFICATE----- > > -------------- 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/20070311/f911f517/attachment.bin From daniella at ripe.net Mon Mar 12 17:03:25 2007 From: daniella at ripe.net (=?ISO-8859-1?Q?Dani=EBlla_Coutinho?=) Date: Mon, 12 Mar 2007 17:03:25 +0100 Subject: [ca-tf] Reimbursements workshop 13 February 2007 Message-ID: <45F579CD.5020807@ripe.net> Dear Task Force members, Until now we only received a request for reimbursement from one task force member. If you would like to have the costs of the workshop on 13 February at Schiphol reimbursed, please follow the procedure below. 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 and IBAN 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 Please let me know if you have any questions. Kind regards, Dani?lla Coutinho Management Assistant RIPE NCC From robert at ripe.net Thu Mar 15 15:16:34 2007 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 15 Mar 2007 15:16:34 +0100 Subject: [ca-tf] Resource certification related drafts Message-ID: <45F95542.7010108@ripe.net> Dear All, I've updated the web page (http://ca-trial.ripe.net/) to include links to the relevant IETF SIDR working group drafts. Please look at them if you have the time. Regards, Robert From filiz at ripe.net Fri Mar 16 16:00:05 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Fri, 16 Mar 2007 16:00:05 +0100 Subject: [ca-tf] food for thought Message-ID: <20070316150004.GA31439@ripe.net> Dear TF Members, Here is the list of main policy topics that came up during the TF meeting in February. >From your feedback and comments so far, I gather we will need to look at the following broad areas in regards to certification and policy: 1. ERX/Legacy space seems to be an open issue and needs more discussion. 2. A new transfer policy is very likely to be needed. It will be important to ensure the resources are transferred to a single entity and uniqueness is preserved while the certificated resources change hands. Transfers of resources from one RIR region to another may become common with the introduction of certifications too. Users may benefit from some guidelines/policies on these as well. As a side note to this, in ARIN region there is a new proposal looking at current tranfers of resources. The proposal itself is more for an effort for clarification in the policy on what can be transfered. However, the discussions around it also touched the topic of whether or not ARIN is "leasing" resources as the RIR. You can see the thread on this at: http://lists.arin.net/pipermail/ppml/2007-March/thread.html if you are interested. 3. Some new policies outlining how certificates are issued by the RIPE NCC and on what basis will be useful. This is not in the scope of Address Policy as such but it is to serve as a guideline to help a clear start for users of the certificates. It is also not in the scope of such a guideline to define the detailed procedure of certification. However, a guideline which sets the goals and the service the RIPE NCC will be providing might be useful. I am wondering what your ideas are on how and when these issues above should be looked at. In your report to the community during the next RIPE meeting, I believe some will appear as open issues for further discussion. Some questions I have at this point are: - Would a discussion document help to stimulate such discussions? - I also assume you will make a presentation in the next RIPE meeting as part of your reporting to the community. Leaving these items as open questions on the slides may be another way of starting the discussions around them to get community feedback. Would you like me to help in drafting such slides? - Did I miss any topics that should appear in the list above? Also, if there is any other specific issue you would like me to look at and report back, please let me know. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer