From morrowc.lists at gmail.com Tue Dec 4 15:18:51 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Dec 2012 15:18:51 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... Message-ID: howdy, in the SIDR working group in the IETF there's some discussion about the ARIN RPA (Relying Party Agreement), and the fact that perhaps users of the ARIN RPKI Publication Repository will need to acknowledge/sign the RPA in order to get access to the data in the repository? The RPA is: Particularly the first paragraph: "YOU MUST READ AND ACCEPT THIS RESOURCE CERTIFICATION RELYING PARTY AGREEMENT (THIS ?AGREEMENT?) BEFORE ACCESSING OR USING ANY ONLINE RESOURCE CERTIFICATION PKI (?ORCP?) SERVICES (AS DEFINED BELOW). IN CONSIDERATION OF ARIN PROVIDING YOU WITH THE ABILITY TO USE THE ORCP SERVICES, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, DO NOT SUBMIT A QUERY OR OTHERWISE USE ANY ORCP SERVICES." This seems, to me, mean that people outside the ARIN region, those like in RIPE area, will have to sign something they don't know they have to sign and ?? This seems confusing and counter productive.... what's up? From morrowc.lists at gmail.com Tue Dec 4 15:24:29 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 4 Dec 2012 15:24:29 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: Message-ID: Oh! I'm reminded (by a kind reader) that micheal sinatra was going to bring this up here... maybe he got busy? in the end... still, how is this envisioned to work? (I recall micheal had some ideas as to how/why... Micheal?) On Tue, Dec 4, 2012 at 3:18 PM, Christopher Morrow wrote: > howdy, > in the SIDR working group in the IETF there's some discussion about > the ARIN RPA (Relying Party Agreement), and the fact that perhaps > users of the ARIN RPKI Publication Repository will need to > acknowledge/sign the RPA in order to get access to the data in the > repository? The RPA is: > > > Particularly the first paragraph: > "YOU MUST READ AND ACCEPT THIS RESOURCE CERTIFICATION RELYING PARTY > AGREEMENT (THIS > ?AGREEMENT?) BEFORE ACCESSING OR USING ANY ONLINE RESOURCE > CERTIFICATION PKI (?ORCP?) > SERVICES (AS DEFINED BELOW). IN CONSIDERATION OF ARIN PROVIDING YOU > WITH THE ABILITY TO USE > THE ORCP SERVICES, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU DO > NOT AGREE TO THE > TERMS OF THIS AGREEMENT, DO NOT SUBMIT A QUERY OR OTHERWISE USE ANY > ORCP SERVICES." > > This seems, to me, mean that people outside the ARIN region, those > like in RIPE area, will have to sign something they don't know they > have to sign and ?? > > This seems confusing and counter productive.... what's up? From farmer at umn.edu Tue Dec 4 16:12:53 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 04 Dec 2012 15:12:53 -0600 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: Message-ID: <50BE6755.3030801@umn.edu> Chris, This was discussed a little on the ARIN-Tech-Discuss list back in October, and was in the RPKI Demo presentation in Dallas, "Step 3 Becoming a Relying Party", Slide 25; http://lists.arin.net/pipermail/arin-tech-discuss/2012-October/000241.html https://www.arin.net/participate/meetings/reports/ARIN_XXX/ppm.html But, it is worthy of more discussion. On 12/4/12 14:24 , Christopher Morrow wrote: > Oh! I'm reminded (by a kind reader) that micheal sinatra was going to > bring this up here... maybe he got busy? in the end... still, how is > this envisioned to work? > > (I recall micheal had some ideas as to how/why... Micheal?) > > On Tue, Dec 4, 2012 at 3:18 PM, Christopher Morrow > wrote: >> howdy, >> in the SIDR working group in the IETF there's some discussion about >> the ARIN RPA (Relying Party Agreement), and the fact that perhaps >> users of the ARIN RPKI Publication Repository will need to >> acknowledge/sign the RPA in order to get access to the data in the >> repository? The RPA is: >> >> >> Particularly the first paragraph: >> "YOU MUST READ AND ACCEPT THIS RESOURCE CERTIFICATION RELYING PARTY >> AGREEMENT (THIS >> ?AGREEMENT?) BEFORE ACCESSING OR USING ANY ONLINE RESOURCE >> CERTIFICATION PKI (?ORCP?) >> SERVICES (AS DEFINED BELOW). IN CONSIDERATION OF ARIN PROVIDING YOU >> WITH THE ABILITY TO USE >> THE ORCP SERVICES, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU DO >> NOT AGREE TO THE >> TERMS OF THIS AGREEMENT, DO NOT SUBMIT A QUERY OR OTHERWISE USE ANY >> ORCP SERVICES." >> >> This seems, to me, mean that people outside the ARIN region, those >> like in RIPE area, will have to sign something they don't know they >> have to sign and ?? >> >> This seems confusing and counter productive.... what's up? > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to > the ARIN Discussion Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss > Please contact info at arin.net if you experience any issues. > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jcurran at arin.net Tue Dec 4 16:43:01 2012 From: jcurran at arin.net (John Curran) Date: Tue, 4 Dec 2012 21:43:01 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: Message-ID: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> On Dec 4, 2012, at 3:18 PM, Christopher Morrow wrote: > This seems, to me, mean that people outside the ARIN region, those > like in RIPE area, will have to sign something they don't know they > have to sign and ?? Chris - The only parties that need to acknowledge that RPA are relying parties, and the need to do this once to obtain the TAL. This step insures that relying parties are aware of the terms and conditions associated with ARIN's CA prior to building reliance upon its capabilities, and is baseline requirement contained in RFC 5280 for prospective relying parties prior to them relying on the authentication or non-repudiation services associated with the public key in a particular certificate. Acknowledging the RPA occurs once with the download of ARIN's TAL; while it is an additional step, it's likely to be relatively small compared to the myriad of other tasks involved in setup of any RPKI- based validation. This is also important to ARIN as an organization, as having a record that parties will not rely on the RPKI services at this time for life- critical or environmentally critical (as an example) could be important in some circumstances, and protecting ARIN in the rollout of this new service was deemed a priority by the Board. I encourage discussion of this topic, both here and at our April meeting; I hope this information is helpful input to that process. Thanks! /John John Curran President and CEO ARIN From michael+ppml at burnttofu.net Tue Dec 4 23:21:31 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Tue, 04 Dec 2012 20:21:31 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> Message-ID: <50BECBCB.8000008@burnttofu.net> Michael is traveling now, but he will try to chime in... The issue that I have with the RPA is that it contains a 3rd party indemnification clause that appears to require that I indemnify and defend ARIN against any third-party claims. As such, $my_employer will not allow me to sign such a thing. I can see why there may be a need for such indemnification; presumably it avoids the issues that came up in the early(?) days of the RBLs, where parties denied spamming "rights" through someone's email infrastructure would sue the RBL operator. OTOH, the indemnification clause does *appear* to also cover the case where ARIN is truly negligent in its operation of its RPKI infrastructure. In such a case, I would have to assume the liability and defend ARIN from a *third-party* complaint, even if it were clearly ARIN's fault. Managing my own risks is one thing; managing ARIN's is another. But the practical issue is that I work for an employer that requires, at a minimum, extensive gyrations before I can even click-through such an agreement, which makes piloting RPKI (something I have promised members of the SIDR working group I would do) very difficult and much more time-consuming for me. I am also pretty sure that a similar agreement exists--with 3rd party indemnification clause--for generating ROAs, and must be signed or clicked-through for the ROA process to continue. michael From farmer at umn.edu Wed Dec 5 00:37:06 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 04 Dec 2012 23:37:06 -0600 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <50BECBCB.8000008@burnttofu.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <50BECBCB.8000008@burnttofu.net> Message-ID: <50BEDD82.3020309@umn.edu> On 12/4/12 22:21 , Michael Sinatra wrote: > Michael is traveling now, but he will try to chime in... > > The issue that I have with the RPA is that it contains a 3rd party > indemnification clause that appears to require that I indemnify and > defend ARIN against any third-party claims. As such, $my_employer will > not allow me to sign such a thing. > > I can see why there may be a need for such indemnification; presumably > it avoids the issues that came up in the early(?) days of the RBLs, > where parties denied spamming "rights" through someone's email > infrastructure would sue the RBL operator. > > OTOH, the indemnification clause does *appear* to also cover the case > where ARIN is truly negligent in its operation of its RPKI > infrastructure. In such a case, I would have to assume the liability > and defend ARIN from a *third-party* complaint, even if it were clearly > ARIN's fault. > > Managing my own risks is one thing; managing ARIN's is another. > > But the practical issue is that I work for an employer that requires, at > a minimum, extensive gyrations before I can even click-through such an > agreement, which makes piloting RPKI (something I have promised members > of the SIDR working group I would do) very difficult and much more > time-consuming for me. > > I am also pretty sure that a similar agreement exists--with 3rd party > indemnification clause--for generating ROAs, and must be signed or > clicked-through for the ROA process to continue. Michael, I raised similar issues on an arin-tech-discuss thread back in October. I was thinking that maybe there could be a version of the RPA that was in the form of an addendum to the RSA or LRSA that many organizations in region already have and used the indemnification language from those contracts rather than the new language in the separate agreement. Do you think that is a strategy that could work for your situation? Honestly, I haven't done anything about it, as I haven't got around to doing anything about RPKI yet. Mr. Curran seemed to think something like that could be possible. He also discussed some of the advantages of a formal contract vs. an implied RPA. I think he makes some good points especially for employers like ours. http://lists.arin.net/pipermail/arin-tech-discuss/2012-October/000244.html -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From morrowc.lists at gmail.com Wed Dec 5 01:27:25 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 01:27:25 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <50BE6755.3030801@umn.edu> References: <50BE6755.3030801@umn.edu> Message-ID: On Tue, Dec 4, 2012 at 4:12 PM, David Farmer wrote: > Chris, > > This was discussed a little on the ARIN-Tech-Discuss list back in October, yes, the kind reader pointed me at that as well... I started the thread in a way trolling, but also interested in what the thinking was. I don't see that the RPA helps with rpki deployment, or utilization... folk not in the arin region really don't normally think to poke arin for things like this. I wish the iana would get off the stick and setup their rpki root ... the rest of this isn't helpful. -chris From morrowc.lists at gmail.com Wed Dec 5 01:22:24 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 01:22:24 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <50BECBCB.8000008@burnttofu.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <50BECBCB.8000008@burnttofu.net> Message-ID: On Tue, Dec 4, 2012 at 11:21 PM, Michael Sinatra wrote: > Michael is traveling now, but he will try to chime in... hey thanks! :) > The issue that I have with the RPA is that it contains a 3rd party > indemnification clause that appears to require that I indemnify and > defend ARIN against any third-party claims. As such, $my_employer will > not allow me to sign such a thing. yuck :( that's probably not good for the community... What's confusing to me is that I think the certificate profile for ARIN, in the case of the RPKI, includes statements about what the certificates could be used/depended upon in the CPS, isn't that what the RPA is trying to do? - talks about the cps, and alludes to legal-beagle-ness the cps is: it seems the meat we are interested in is on pages 34-35 though: 8.7. Disclaimers of warranties. ..................................................................... 34 8.8. Exclusion of Liabilities and Damages.................................................. 35 8.9. Limitations of liability. ................................................................ 35 8.10. Indemnification. ............................................................. 35 for instance: 8.8. Exclusion of Liabilities and Damages. NOTWITHSTANDING ANYTHING TO THE CONTRARY, ARIN WILL NOT BE LIABLE TO ANY USER, SUBSCRIBER, RELYING PARTY OR THIRD PARTY, INCLUDING ANY CLIENTS OR CUSTOMERS OF ANY USER,SUBSCRIBER, RELYING PARTY OR THIRD PARTY, FOR ANY LIABILITIES AT LAW OR IN EQUITY OR FOR ANY DAMAGES, INCLUDING CONSEQUENTIAL, INCIDENTAL,INDIRECT, PUNITIVE, EXEMPLARY, OR SPECIAL DAMAGES (INCLUDINGLIABILITIES OR DAMAGES RELATING TO LOST PROFITS, LOST DATA, OR LOSS OFGOODWILL) ARISING OUT OF, RELATING TO, OR CONNECTED WITH ANY RESOURCE CERTIFICATION SERVICES, ANY RESOURCE CERTIFICATION, OR OTHERWISE INCONNECTION THEREWITH, WHETHER BASED ON CONTRACT, TORT, STATUTE, OR ANYCAUSE OF ACTION, EVEN IF ANY USER, SUBSCRIBER, RELYING PARTY OR THIRD PARTY IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 8.9. Limitations of liability. IN NO EVENT, WHETHER BASED ON CONTRACT,TORT, STATUTE, OR ANY CAUSE OF ACTION, WILL ARIN?S LIABILITY TO ANYUSER, SUBSCRIBER, RELYING PARTY OR THIRD PARTY, INCLUDING ANY CLIENTS OR CUSTOMERS OF ANY USER, SUBSCRIBER, RELYING PARTY OR THIRD PARTY, EXCEED IN THE AGGREGATE THE GREATER OF (i) THE AMOUNT PAID BYSUBSCRIBER TO ARIN FOR THE RESOURCE CERTIFICATION SERVICES DURING THE SIX (6) MONTHS IMMEDIATELY PRECEDING THE EVENT THAT GIVES RISE TO SUCHLIABILITY OR (ii) ONE HUNDRED U.S. DOLLARS (US$100.00). If you use the CA and such, you agree to the cps, ideally... :) > I can see why there may be a need for such indemnification; presumably > it avoids the issues that came up in the early(?) days of the RBLs, > where parties denied spamming "rights" through someone's email > infrastructure would sue the RBL operator. > maybe, doesn't the cps cover all of that? (see inclusions above). > OTOH, the indemnification clause does *appear* to also cover the case > where ARIN is truly negligent in its operation of its RPKI > infrastructure. In such a case, I would have to assume the liability > and defend ARIN from a *third-party* complaint, even if it were clearly > ARIN's fault. except that the quoted bit above from the CPS seems to also do the liability shedding... so I'm not sure why another version of the text is required? > Managing my own risks is one thing; managing ARIN's is another. it does seem a bit crazy, yes. > But the practical issue is that I work for an employer that requires, at > a minimum, extensive gyrations before I can even click-through such an > agreement, which makes piloting RPKI (something I have promised members > of the SIDR working group I would do) very difficult and much more > time-consuming for me. > > I am also pretty sure that a similar agreement exists--with 3rd party > indemnification clause--for generating ROAs, and must be signed or > clicked-through for the ROA process to continue. :( From morrowc.lists at gmail.com Wed Dec 5 01:40:21 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 01:40:21 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> Message-ID: On Tue, Dec 4, 2012 at 4:43 PM, John Curran wrote: > On Dec 4, 2012, at 3:18 PM, Christopher Morrow wrote: > >> This seems, to me, mean that people outside the ARIN region, those >> like in RIPE area, will have to sign something they don't know they >> have to sign and ?? > > Chris - > > The only parties that need to acknowledge that RPA are relying parties, > and the need to do this once to obtain the TAL. right, it's not clear to me that they'll know they need to do it though? and they don't in many cases have a relationship with ARIN either. > This step insures that relying parties are aware of the terms and > conditions associated with ARIN's CA prior to building reliance upon doesn't the CPS do this though as well? It's part of the point of the CPS really, I thought. > its capabilities, and is baseline requirement contained in RFC 5280 > for prospective relying parties prior to them relying on the > authentication or non-repudiation services associated with the public > key in a particular certificate. 5280 is an rfc about CRLs and basic pkix x509 certs... > Acknowledging the RPA occurs once with the download of ARIN's TAL; > while it is an additional step, it's likely to be relatively small > compared to the myriad of other tasks involved in setup of any RPKI- > based validation. sure, maybe. it seems like an unnecessary step though, since the same sort of data is in the CPS, i think. > > This is also important to ARIN as an organization, as having a record > that parties will not rely on the RPKI services at this time for life- > critical or environmentally critical (as an example) could be important > in some circumstances, and protecting ARIN in the rollout of this new > service was deemed a priority by the Board. this is covered in the cps, I think...you could certainly add in the 'do not rely on this for life relevant services' if you wanted, but really 8.8 seems to cover it, to me. > I encourage discussion of this topic, both here and at our April meeting; > I hope this information is helpful input to that process. thanks! ... april meeting, must put that on the calendar :) > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > > > > From jcurran at arin.net Wed Dec 5 05:47:56 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 10:47:56 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> Message-ID: <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> On Dec 5, 2012, at 1:40 AM, Christopher Morrow wrote: > doesn't the CPS do this though as well? It's part of the point of the > CPS really, I thought. The CPS is not legally binding on its own; ergo, an organization may not even bother to read it. >> its capabilities, and is baseline requirement contained in RFC 5280 >> for prospective relying parties prior to them relying on the >> authentication or non-repudiation services associated with the public >> key in a particular certificate. > > 5280 is an rfc about CRLs and basic pkix x509 certs... And that RFC states basic requirements needed for the PKIX x509 profile to work successfully, including: " 2. Requirements and Assumptions The goal of this specification is to develop a profile to facilitate the use of X.509 certificates within Internet applications for those communities wishing to make use of X.509 technology. Such applications may include WWW, electronic mail, user authentication, and IPsec. In order to relieve some of the obstacles to using X.509 certificates, this document defines a profile to promote the development of certificate management systems, development of application tools, and interoperability determined by policy. ... A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties. " >> Acknowledging the RPA occurs once with the download of ARIN's TAL; >> while it is an additional step, it's likely to be relatively small >> compared to the myriad of other tasks involved in setup of any RPKI- >> based validation. > > sure, maybe. it seems like an unnecessary step though, since the same > sort of data is in the CPS, i think. It being in the CPS does not mean that an organization has actually considered it; it is the that very evaluation that results from being bound to conditions in the CP/CPS which underlies the purpose of the RPA. >> This is also important to ARIN as an organization, as having a record >> that parties will not rely on the RPKI services at this time for life- >> critical or environmentally critical (as an example) could be important >> in some circumstances, and protecting ARIN in the rollout of this new >> service was deemed a priority by the Board. > > this is covered in the cps, I think...you could certainly add in the > 'do not rely on this for life relevant services' if you wanted, but > really 8.8 seems to cover it, to me. See above: not legally binding and may not even be seen unless referenced in actual agreement (and I'm not sure we all want to live in a world where terms of a CPS bind simply by verifying the certificates that come out of the associated CA...) FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Dec 5 06:04:08 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 11:04:08 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <50BECBCB.8000008@burnttofu.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <50BECBCB.8000008@burnttofu.net> Message-ID: <582B83BE-E885-4F80-AF1A-5006E3005218@arin.net> On Dec 4, 2012, at 11:21 PM, Michael Sinatra wrote: > Michael is traveling now, but he will try to chime in... > > The issue that I have with the RPA is that it contains a 3rd party > indemnification clause that appears to require that I indemnify and > defend ARIN against any third-party claims. As such, $my_employer will > not allow me to sign such a thing. > > I can see why there may be a need for such indemnification; presumably > it avoids the issues that came up in the early(?) days of the RBLs, > where parties denied spamming "rights" through someone's email > infrastructure would sue the RBL operator. Or if someone makes a typo in their use of RPKI services, and then is sued by a relying party (e.g. a now failing financial institution or telesurgery firm) and decides that it is easiest to simply say ARIN's systems failed. We take some very serious precautions in establishing the RPKI services, including dedicated HSMs, non-repudiation mechanisms, multiple party controls, and a threat model that includes some fairly byzantine cases. At the end of the day, however, parties must actually consider the fact that relying on RPKI could create some additional failure modes, particularly if best practices are used in how route evaluation is performed. > OTOH, the indemnification clause does *appear* to also cover the case > where ARIN is truly negligent in its operation of its RPKI > infrastructure. In such a case, I would have to assume the liability > and defend ARIN from a *third-party* complaint, even if it were clearly > ARIN's fault. > > Managing my own risks is one thing; managing ARIN's is another. If ARIN were clearly at fault (e.g. gross negligence or malfeasance on ARIN's part), then applicable of indemnification clause is a legal question which is best answered by your counsel. > But the practical issue is that I work for an employer that requires, at > a minimum, extensive gyrations before I can even click-through such an > agreement, which makes piloting RPKI (something I have promised members > of the SIDR working group I would do) very difficult and much more > time-consuming for me. Your organization has certain expectations about the risks they take on, and relying on ARIN's CA data in a programmatic way could easily increase those risks due to new failure modes. ARIN has made those risks fairly explicit in the RPA and associated CPS, and is willing to provide the service but cannot possible know what dependence you or your business partners will be making on its services. As such, we have to be clear that the risks associated with relying on this data are fully borne by the relying party. Thanks! /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Wed Dec 5 13:16:11 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 13:16:11 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> Message-ID: On Wed, Dec 5, 2012 at 5:47 AM, John Curran wrote: > ... > A certificate user should review the certificate policy generated by > the certification authority (CA) before relying on the authentication > or non-repudiation services associated with the public key in a > particular certificate. To this end, this standard does not > prescribe legally binding rules or duties. that's a bummer ;( Do other certificate/CA people require you to download and agree to an RPA-like thing before using their services? (I'm thinking of like Thawte, CN-NIC, Verisign^H^H^H^H^HSymantec, GlobalTrust, etc?) I don't think they do, why don't they? Their certs could be used to sign things on 'emergency services/etc' things, no? I'm concerned that we're being more cautious than is reasonable, and imposing some odd constraints/requirements on the global userbase. -chris From jcurran at arin.net Wed Dec 5 13:37:04 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 18:37:04 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> Message-ID: <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> On Dec 5, 2012, at 1:16 PM, Christopher Morrow wrote: > On Wed, Dec 5, 2012 at 5:47 AM, John Curran wrote: >> ... >> A certificate user should review the certificate policy generated by >> the certification authority (CA) before relying on the authentication >> or non-repudiation services associated with the public key in a >> particular certificate. To this end, this standard does not >> prescribe legally binding rules or duties. > > that's a bummer ;( > Do other certificate/CA people require you to download and agree to an > RPA-like thing before using their services? (I'm thinking of like > Thawte, CN-NIC, Verisign^H^H^H^H^HSymantec, GlobalTrust, etc?) I don't > think they do, why don't they? Their certs could be used to sign > things on 'emergency services/etc' things, no? You would have to check such parties about the terms and conditions on their services. > I'm concerned that we're being more cautious than is reasonable, and > imposing some odd constraints/requirements on the global userbase. As I noted earlier, my guidance was to provide the RPKI services without posing undue risk to ARIN's existing mission. As a result, we need a real relying partying agreement that makes plain the conditions of the service. I'll note that we've also received praise from some folks who appreciate ARIN's level of due diligence in this area, given that operators could be adding a new component of risk to their existing business based on using RPKI information from other parties, and accepting such risks is a decision that should be made at an organizational level. FYI, /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Wed Dec 5 13:51:09 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 13:51:09 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: On Wed, Dec 5, 2012 at 1:37 PM, John Curran wrote: > I'll note that we've also received praise from some folks who appreciate > ARIN's level of due diligence in this are sure, there's always 2 sides to a coin... not counting the ridged edge, of course. So, looking to the future, what happens if/when IANA (or someone) becomes a single-root for the RPKI? Does the RPA requirement go away at that point? -chris From morrowc.lists at gmail.com Wed Dec 5 13:53:36 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 13:53:36 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: On Wed, Dec 5, 2012 at 1:37 PM, John Curran wrote: > accepting such risks is a decision > that should be made at an organizational level. oops, I was snip-happy previously... it's probably interesting to note that today some folks depend on (probably a LOT more than expect so) upon the IP infrastructure that is the 'Internet' (manning will jump in here...yes 'the internet') to transact business which is life/death related. I don't think there have been court cases which dragged in IP providers previously for routing problems, or hijacks even, that have affected said services. anyway, cautious is good, overly so... isn't as helpful :( or that's what it looks like, to me. -chris From jcurran at arin.net Wed Dec 5 14:17:37 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 19:17:37 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: <72EB4AF1-7C00-4B1E-B3F3-D32A5B0CD39E@arin.net> On Dec 5, 2012, at 1:51 PM, Christopher Morrow wrote: > On Wed, Dec 5, 2012 at 1:37 PM, John Curran wrote: >> I'll note that we've also received praise from some folks who appreciate >> ARIN's level of due diligence in this are > > sure, there's always 2 sides to a coin... not counting the ridged > edge, of course. > > So, looking to the future, what happens if/when IANA (or someone) > becomes a single-root for the RPKI? Does the RPA requirement go away > at that point? ARIN's participation in a global trust anchor (GTA) is predicated on it only being made available to parties who have agreed to use data in our CA conformance with our CPS. This does not preclude a global trust anchor (as folks that rely on certificates already need to keep their usage in conformance with the associated CP and CPS statements) but does mean getting an acknowledgement of this basic RPKI principle recorded first. See RFC 3647, the Internet X.509 framework for a good discussion of CP/CPS interaction with legal agreements. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Dec 5 14:36:09 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 19:36:09 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: On Dec 5, 2012, at 1:53 PM, Christopher Morrow wrote: > oops, I was snip-happy previously... it's probably interesting to note > that today some folks depend on (probably a LOT more than expect so) > upon the IP infrastructure that is the 'Internet' (manning will jump > in here...yes 'the internet') to transact business which is life/death > related. I don't think there have been court cases which dragged in IP > providers previously for routing problems, or hijacks even, that have > affected said services. First, those parties are generally under service agreements with ISPs which require them effectively to defend, indemnify and hold harmless the ISPs for use of the service. So if a business is unavailable to its business partner, the business can't hold its ISP liable, and it is highly likely that the business partner has a similar situation with its service provider. Neither have a direct relationship with the others ISP, not receive or make use directly of any information or service from the other's ISP. Contrast this with RPKI, where ARIN's CA may be depended upon by many parties which otherwise have no relationship with ARIN, i.e. the business partner who is harmed by RPKI usage by either their own failure or by an upstream ISP not following best practices could easily be validating routes via information obtained from ARIN's CA. If the business entered the wrong AS in a ROA (but denies it after the fact), ARIN could face significant legal action just proving that we performed correctly. Hence, there is a real need for both system capabilities (in areas such as non- repudiation) as well as appropriate legal protections. FYI, /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Wed Dec 5 14:40:05 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 14:40:05 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: On Wed, Dec 5, 2012 at 2:36 PM, John Curran wrote: > If the business entered > the wrong AS in a ROA (but denies it after the fact), ARIN could face > significant legal action just proving that we performed correctly. this is a logging and auditing problem, no? why not just gather all data under the ARIN umbrella, log it and store those for X years? and make that data available via restful-webquery? (there are probably other concerns, but this one seems simple to sidestep...) From owen at delong.com Wed Dec 5 14:52:54 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 11:52:54 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: On Dec 5, 2012, at 11:36 AM, John Curran wrote: > On Dec 5, 2012, at 1:53 PM, Christopher Morrow wrote: > >> oops, I was snip-happy previously... it's probably interesting to note >> that today some folks depend on (probably a LOT more than expect so) >> upon the IP infrastructure that is the 'Internet' (manning will jump >> in here...yes 'the internet') to transact business which is life/death >> related. I don't think there have been court cases which dragged in IP >> providers previously for routing problems, or hijacks even, that have >> affected said services. > > First, those parties are generally under service agreements with ISPs > which require them effectively to defend, indemnify and hold harmless > the ISPs for use of the service. So if a business is unavailable to > its business partner, the business can't hold its ISP liable, and it > is highly likely that the business partner has a similar situation > with its service provider. Neither have a direct relationship with > the others ISP, not receive or make use directly of any information > or service from the other's ISP. I, as a Hurricane Electric customer, often depend on services provided by $OTHER_ISP to reach sites critical to my business. Consider the following scenario: $ME <-> $MY_ISP <-> $TRANSIT_ISP_1 <-> $TRANSIT_ISP_2 <-> $OTHER_ISP <-> $WEBSITE It's possible that I have indemnified $MY_ISP. It's possible that $WEBSITE has indemnified $OTHER_ISP. It's very unlikely that either of us has indemnified $TRANSITE_ISP_1 or $TRANSIT_ISP_2 or has a contract with either of them at all. I may not be able to hold $MY_ISP liable, but that doesn't necessarily prevent me from suing any of the other ISPs down the chain. Of that chain, the only one likely to be indemnified by the $WEBSITE I'm trying to reach would be $OTHER_ISP. > Contrast this with RPKI, where ARIN's CA may be depended upon by many > parties which otherwise have no relationship with ARIN, i.e. the business > partner who is harmed by RPKI usage by either their own failure or by > an upstream ISP not following best practices could easily be validating > routes via information obtained from ARIN's CA. If the business entered > the wrong AS in a ROA (but denies it after the fact), ARIN could face > significant legal action just proving that we performed correctly. Hence, > there is a real need for both system capabilities (in areas such as non- > repudiation) as well as appropriate legal protections. I guess the question boils down to this? 1. Do we want RPKI to get deployed? If so, then we need to accept some risks in doing so, because the RPA is likely to be an insurmountable barrier to deployment. 2. Are there alternative ways ARIN could mitigate the risks? (e.g. Create a separate corporation that is contracted by ARIN to administer the RPKI and CA infrastructures such that ARIN as a shareholder is not liable. The corporation would not have enough assets to be worth suing.) Owen From wesley.george at twcable.com Wed Dec 5 15:21:50 2012 From: wesley.george at twcable.com (George, Wes) Date: Wed, 5 Dec 2012 15:21:50 -0500 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> Replying to http://lists.arin.net/pipermail/arin-discuss/2012-December/002340.html Apologies for the weird quoting method, I don't have the actual email to reply to because I was following this thread via the archive until just now when I subscribed/delurked. * From: John Curran (jcurran at arin.net) On Dec 5, 2012, at 1:16 PM, Christopher Morrow > wrote: > Do other certificate/CA people require you to download and agree to an > RPA-like thing before using their services? (I'm thinking of like > Thawte, CN-NIC, Verisign^H^H^H^H^HSymantec, GlobalTrust, etc?) I don't > think they do, why don't they? Their certs could be used to sign > things on 'emergency services/etc' things, no? You would have to check such parties about the terms and conditions on their services. [WEG] Sorry John, that's kind of a cop-out answer to a legitimate question. I am neither a lawyer, a CEO, nor an expert when it comes to PKI, but If I were being asked to set up a procedural and contractual framework for a new type of PKI that had potentially nasty new failure modes and questions over liability, one of the first places I would look for precedent and clues would be existing CAs, with a specific eye toward whether they use the indemnification/hold harmless model vs something less stringent like "no warranty" or if they instead acknowledge that there is a potential for liability if there is demonstrable negligence on the part of the CA. I'd even be looking to see if there were relevant cases stemming from the breaches of Diginotar and Comodo that dealt with liability/negligence, especially as it related to third-party involvement. Are you telling me that as a part of ARIN's lengthy due dilligence regarding the legal issues surrounding this that you didn't look at this for guidance? As a related question to Chris's, is there something about the operating agreement that the other RIRs have in place with their members or the laws in the region in which they're incorporated that hasn't made them all say "aha, ARIN is right, we should all implement an RPA lest we get sued" ? As I noted earlier, my guidance was to provide the RPKI services without posing undue risk to ARIN's existing mission [WEG] It's possible that these are mutually exclusive goals. Unless there is precedent to the contrary, I think it is a reasonable expectation that if you wish to be trusted as a certificate authority or TA, you have to have the necessary documented rigor in your processes and methods to be seen as a trustworthy source, such that it is defensible when someone comes back trying to blame you when something goes pear-shaped. A signed contract indemnifying you is unlikely to prevent savvy lawyers from trying to prove demonstrable negligence if they believe that it exists, while proof that you have good process in place and you followed it exactly but something happened beyond your control will go a long way. Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Dec 5 16:02:59 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 21:02:59 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: On Dec 5, 2012, at 2:52 PM, Owen DeLong wrote: > $ME <-> $MY_ISP <-> $TRANSIT_ISP_1 <-> $TRANSIT_ISP_2 <-> $OTHER_ISP <-> $WEBSITE > > It's possible that I have indemnified $MY_ISP. It's possible that $WEBSITE > has indemnified $OTHER_ISP. > > It's very unlikely that either of us has indemnified $TRANSITE_ISP_1 or > $TRANSIT_ISP_2 or has a contract with either of them at all. > > I may not be able to hold $MY_ISP liable, but that doesn't necessarily > prevent me from suing any of the other ISPs down the chain. Of that > chain, the only one likely to be indemnified by the $WEBSITE I'm > trying to reach would be $OTHER_ISP. Of course, nothing prevents you from suing anyone you wish... (Welcome to the US legal system) However, in the scenario above you also don't have any services being provided to you by those intermediate parties, whereas with RPKI you are making use of, and relying specifically upon, ARIN's CA and RPKI services. This changes the situation significantly from a liability perspective. The guidance from the Board is to provide these new services without incurring significant additional risk to our mission. It is not solely a legal concern; making use of RPKI without appropriate safeguard (such as following best practices for handling route preferences) could readily result in serious impacts to uninvolved parties. We believe that accomplished the goal of providing the services a minimum of effort required for relying parties in the form of a simple acknowledgment of the RPA when obtaining the ARIN's TAL. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Dec 5 16:18:22 2012 From: jcurran at arin.net (John Curran) Date: Wed, 5 Dec 2012 21:18:22 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> Message-ID: <272DF52B-BE9D-4D9B-80DE-8834C01DB25C@arin.net> On Dec 5, 2012, at 3:21 PM, "George, Wes" > wrote: [WEG] Sorry John, that?s kind of a cop-out answer to a legitimate question. I am neither a lawyer, a CEO, nor an expert when it comes to PKI, but If I were being asked to set up a procedural and contractual framework for a new type of PKI that had potentially nasty new failure modes and questions over liability, one of the first places I would look for precedent and clues would be existing CAs, with a specific eye toward whether they use the indemnification/hold harmless model vs something less stringent like ?no warranty? or if they instead acknowledge that there is a potential for liability if there is demonstrable negligence on the part of the CA. I?d even be looking to see if there were relevant cases stemming from the breaches of Diginotar and Comodo that dealt with liability/negligence, especially as it related to third-party involvement. Are you telling me that as a part of ARIN?s lengthy due dilligence regarding the legal issues surrounding this that you didn?t look at this for guidance? As a related question to Chris?s, is there something about the operating agreement that the other RIRs have in place with their members or the laws in the region in which they?re incorporated that hasn?t made them all say ?aha, ARIN is right, we should all implement an RPA lest we get sued? ? Wes - We've done extensively legal work, but outlining the circumstances of potential liability publicly is not something that makes sense for ARIN to do. If you obtain commercial certificates (e.g. SSL), you will generally find that you enter into agreements that require you provide indemnification to the provider based on your use of the certificate. [WEG] It?s possible that these are mutually exclusive goals. Unless there is precedent to the contrary, I think it is a reasonable expectation that if you wish to be trusted as a certificate authority or TA, you have to have the necessary documented rigor in your processes and methods to be seen as a trustworthy source, such that it is defensible when someone comes back trying to blame you when something goes pear-shaped. Indeed. In fact, we likely are stronger there in terms of process and systems than anyone would expect. A signed contract indemnifying you is unlikely to prevent savvy lawyers from trying to prove demonstrable negligence if they believe that it exists, while proof that you have good process in place and you followed it exactly but something happened beyond your control will go a long way. Agreed. I am not at all worried about our performance or any fault on ARIN's part, but that will not deter a multiyear litigation over proving exactly that fact. This is why an indemnification is rather important, because it reduces the potential for such litigation upfront, and hence why it is a standard component of many types of service contracts including ISP and certificate providers. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Wed Dec 5 16:33:02 2012 From: woody at pch.net (Bill Woodcock) Date: Wed, 5 Dec 2012 13:33:02 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> Message-ID: <97606E9D-A5E4-45D6-AF5F-162569830D47@pch.net> On Dec 5, 2012, at 12:21 PM, "George, Wes" wrote: > Is there something about the operating agreement that the other RIRs have in place with their members or the laws in the region in which they?re incorporated that hasn?t made them all say ?aha, ARIN is right, we should all implement an RPA lest we get sued? ? All four of them are in less litigious societies and jurisdictions. Two of them aren't following us because they moved before we did. The other two aren't following us because they haven't moved yet. -Bill From woody at pch.net Wed Dec 5 16:39:57 2012 From: woody at pch.net (Bill Woodcock) Date: Wed, 5 Dec 2012 13:39:57 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: <5822A6A6-84D7-4140-A2E5-CDBDA5862347@pch.net> On Dec 5, 2012, at 11:52 AM, Owen DeLong wrote: > 2. Are there alternative ways ARIN could mitigate the risks? > (e.g. Create a separate corporation that is contracted by > ARIN to administer the RPKI and CA infrastructures such that > ARIN as a shareholder is not liable. The corporation would > not have enough assets to be worth suing.) Puppets created for the purpose of evading liability are generally held to be just that, and not effective. -Bill From owen at delong.com Wed Dec 5 17:18:07 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 14:18:07 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <272DF52B-BE9D-4D9B-80DE-8834C01DB25C@arin.net> References: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> <272DF52B-BE9D-4D9B-80DE-8834C01DB25C@arin.net> Message-ID: On Dec 5, 2012, at 13:18 , John Curran wrote: > On Dec 5, 2012, at 3:21 PM, "George, Wes" wrote: > >> [WEG] Sorry John, that?s kind of a cop-out answer to a legitimate question. I am neither a lawyer, a CEO, nor an expert when it comes to PKI, but If I were being asked to set up a procedural and contractual framework for a new type of PKI that had potentially nasty new failure modes and questions over liability, one of the first places I would look for precedent and clues would be existing CAs, with a specific eye toward whether they use the indemnification/hold harmless model vs something less stringent like ?no warranty? or if they instead acknowledge that there is a potential for liability if there is demonstrable negligence on the part of the CA. I?d even be looking to see if there were relevant cases stemming from the breaches of Diginotar and Comodo that dealt with liability/negligence, especially as it related to third-party involvement. >> Are you telling me that as a part of ARIN?s lengthy due dilligence regarding the legal issues surrounding this that you didn?t look at this for guidance? As a related question to Chris?s, is there something about the operating agreement that the other RIRs have in place with their members or the laws in the region in which they?re incorporated that hasn?t made them all say ?aha, ARIN is right, we should all implement an RPA lest we get sued? ? > > Wes - > > We've done extensively legal work, but outlining the circumstances of > potential liability publicly is not something that makes sense for ARIN > to do. If you obtain commercial certificates (e.g. SSL), you will generally > find that you enter into agreements that require you provide indemnification > to the provider based on your use of the certificate. But the purchaser (web site) is rarely the relying party (visitor to web site). With ARIN RPKI, you've seriously expanded and effectively reversed the nature of the contractual relationship in the creation of the RPA. You're not only requiring those receiving certificates to sign, you're requiring those obtaining certificate data to sign. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Dec 5 17:25:11 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 14:25:11 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <5822A6A6-84D7-4140-A2E5-CDBDA5862347@pch.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> <5822A6A6-84D7-4140-A2E5-CDBDA5862347@pch.net> Message-ID: <00577474-503E-4547-BDE3-97F29F7D6F7F@delong.com> On Dec 5, 2012, at 13:39 , Bill Woodcock wrote: > > On Dec 5, 2012, at 11:52 AM, Owen DeLong wrote: >> 2. Are there alternative ways ARIN could mitigate the risks? >> (e.g. Create a separate corporation that is contracted by >> ARIN to administer the RPKI and CA infrastructures such that >> ARIN as a shareholder is not liable. The corporation would >> not have enough assets to be worth suing.) > > Puppets created for the purpose of evading liability are generally held to be just that, and not effective. > > -Bill > Then please explain $BACKHOE_OPERATOR to me since that seems to be the method under which that entire industry operates. Dig up a fiber? Transfer all assets to $NEW_CORPORATION, declare bankruptcy, and terminate operations. Owen From woody at pch.net Wed Dec 5 18:00:47 2012 From: woody at pch.net (Bill Woodcock) Date: Wed, 5 Dec 2012 15:00:47 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <00577474-503E-4547-BDE3-97F29F7D6F7F@delong.com> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> <5822A6A6-84D7-4140-A2E5-CDBDA5862347@pch.net> <00577474-503E-4547-BDE3-97F29F7D6F7F@delong.com> Message-ID: On Dec 5, 2012, at 2:25 PM, Owen DeLong wrote: > Dig up a fiber? Transfer all assets to $NEW_CORPORATION, declare bankruptcy, and terminate operations. Works if the assets are less than the cost of pursuing them. Not useful in ARIN's case. I don't think you want ARIN terminating operation. -Bill From jesse at la-broadband.com Wed Dec 5 17:36:25 2012 From: jesse at la-broadband.com (Jesse D. Geddis) Date: Wed, 5 Dec 2012 22:36:25 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: Message-ID: As a hurricane electric customer? :D You meant employee of course. http://www.linkedin.com/in/owendelong Current Position - 1. Hurricane Electric 2. ARIN 3. Santa Clara Emergency Wireless Network Just "keepin' it real" As far as creating shell companies with the intention of creating empty vassels to hide liability it doesn't work. Everyone recognizes it for the shell game it is and having been involved in enough lawsuits I can say with experience I've blown through 3 separate shell companies to get to a fourth in just one filing. Each one with thousands of pages of BS trying to shield liability from the next. The answer is to do the job you set out to and do it well. Cases that have no merit generally don't get passed the first request for dismissal. With that said, I think ARIN should do RPKI. As far as this silly legal discussion there is much more liability in how open and lax the current security is as far as mail-from and md5 passwords or whatever ;) ARIN is already involved. I think we'd be fooling ourselves to say this is somehow venturing into new territory for ARIN and increasing liability. ARIN already provides a free RR. This is just added security that is sorely needed. -- Jesse D. Geddis LA Broadband LLC (626) 675-3176 AS 16602 On 12/5/12 11:52 AM, "Owen DeLong" wrote: On Dec 5, 2012, at 11:36 AM, John Curran wrote: > On Dec 5, 2012, at 1:53 PM, Christopher Morrow >wrote: > >> oops, I was snip-happy previously... it's probably interesting to note >> that today some folks depend on (probably a LOT more than expect so) >> upon the IP infrastructure that is the 'Internet' (manning will jump >> in here...yes 'the internet') to transact business which is life/death >> related. I don't think there have been court cases which dragged in IP >> providers previously for routing problems, or hijacks even, that have >> affected said services. > > First, those parties are generally under service agreements with ISPs > which require them effectively to defend, indemnify and hold harmless > the ISPs for use of the service. So if a business is unavailable to > its business partner, the business can't hold its ISP liable, and it > is highly likely that the business partner has a similar situation > with its service provider. Neither have a direct relationship with > the others ISP, not receive or make use directly of any information > or service from the other's ISP. I, as a Hurricane Electric customer, often depend on services provided by $OTHER_ISP to reach sites critical to my business. Consider the following scenario: $ME <-> $MY_ISP <-> $TRANSIT_ISP_1 <-> $TRANSIT_ISP_2 <-> $OTHER_ISP <-> $WEBSITE It's possible that I have indemnified $MY_ISP. It's possible that $WEBSITE has indemnified $OTHER_ISP. It's very unlikely that either of us has indemnified $TRANSITE_ISP_1 or $TRANSIT_ISP_2 or has a contract with either of them at all. I may not be able to hold $MY_ISP liable, but that doesn't necessarily prevent me from suing any of the other ISPs down the chain. Of that chain, the only one likely to be indemnified by the $WEBSITE I'm trying to reach would be $OTHER_ISP. > Contrast this with RPKI, where ARIN's CA may be depended upon by many > parties which otherwise have no relationship with ARIN, i.e. the business > partner who is harmed by RPKI usage by either their own failure or by > an upstream ISP not following best practices could easily be validating > routes via information obtained from ARIN's CA. If the business entered > the wrong AS in a ROA (but denies it after the fact), ARIN could face > significant legal action just proving that we performed correctly. >Hence, > there is a real need for both system capabilities (in areas such as non- > repudiation) as well as appropriate legal protections. I guess the question boils down to this? 1. Do we want RPKI to get deployed? If so, then we need to accept some risks in doing so, because the RPA is likely to be an insurmountable barrier to deployment. 2. Are there alternative ways ARIN could mitigate the risks? (e.g. Create a separate corporation that is contracted by ARIN to administer the RPKI and CA infrastructures such that ARIN as a shareholder is not liable. The corporation would not have enough assets to be worth suing.) Owen _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From jesse at la-broadband.com Wed Dec 5 18:28:49 2012 From: jesse at la-broadband.com (Jesse D. Geddis) Date: Wed, 5 Dec 2012 23:28:49 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <00577474-503E-4547-BDE3-97F29F7D6F7F@delong.com> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> <5822A6A6-84D7-4140-A2E5-CDBDA5862347@pch.net>, <00577474-503E-4547-BDE3-97F29F7D6F7F@delong.com> Message-ID: <1fa78d4336ef4f35aea244b6c7a35d94@mail01-lax01.la-broadband.org> Are we having a serious conversation here? Are we trying to shell script emails? Can we please focus on the topic at hand. This is off on a rabbit trail that, quite frankly, is totally irrelevant to this discussion. _______________ Jesse Geddis ________________________________________ From: arin-discuss-bounces at arin.net on behalf of Owen DeLong Sent: Wednesday, December 5, 2012 2:25 PM To: Bill Woodcock Cc: arin-discuss Subject: Re: [arin-discuss] Question about the ARIN Relying Party Agreement???? - RPKI 'everyone must sign' and such... On Dec 5, 2012, at 13:39 , Bill Woodcock wrote: > > On Dec 5, 2012, at 11:52 AM, Owen DeLong wrote: >> 2.?? Are there alternative ways ARIN could mitigate the risks? >>????? (e.g. Create a separate corporation that is contracted by >>????? ARIN to administer the RPKI and CA infrastructures such that >>????? ARIN as a shareholder is not liable. The corporation would >>????? not have enough assets to be worth suing.) > > Puppets created for the purpose of evading liability are generally held to be just that, and not effective. > >??????????????????????????????? -Bill > Then please explain $BACKHOE_OPERATOR to me since that seems to be the method under which that entire industry operates. Dig up a fiber? Transfer all assets to $NEW_CORPORATION, declare bankruptcy, and terminate operations. Owen _______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net if you experience any issues. From jcurran at arin.net Thu Dec 6 20:47:38 2012 From: jcurran at arin.net (John Curran) Date: Fri, 7 Dec 2012 01:47:38 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <2671C6CDFBB59E47B64C10B3E0BD59230338CCD5D6@PRVPEXVS15.corp.twcable.com> <272DF52B-BE9D-4D9B-80DE-8834C01DB25C@arin.net> Message-ID: On Dec 5, 2012, at 5:18 PM, Owen DeLong > wrote: On Dec 5, 2012, at 13:18 , John Curran > wrote: Wes - We've done extensively legal work, but outlining the circumstances of potential liability publicly is not something that makes sense for ARIN to do. If you obtain commercial certificates (e.g. SSL), you will generally find that you enter into agreements that require you provide indemnification to the provider based on your use of the certificate. But the purchaser (web site) is rarely the relying party (visitor to web site). Correct. In the case of an SSL certificate, the organization obtaining it is generally the harmed party if something goes wrong or they misuse it (e.g. Internet users can't get to their application, or receive an interesting warning,etc.) While the relying party is technically the end-user and his browser, the consequences for any one user is really quite low. The user may not indemnify the certificate provider as a result, but the organization obtaining the certificate does. With ARIN RPKI, you've seriously expanded and effectively reversed the nature of the contractual relationship in the creation of the RPA. You're not only requiring those receiving certificates to sign, you're requiring those obtaining certificate data to sign. Those validating certificates are "relying parties", and yes, we require them to have a "relying party agreement." Note that in this case, the relying party is likely to be an entire organization or service provider, as opposed to a single user, and the consequences of incorrect usage could be quite extensive and impacting many parties who are downstream of the relying party. The scale and potential for consequences to entire organizations otherwise unaware of the use the technology more than warrants seeking indemnification from relying parties, just as organizations using certificates for the web sites provide it their service providers, FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael+ppml at burnttofu.net Thu Dec 6 20:49:05 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Thu, 06 Dec 2012 17:49:05 -0800 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> Message-ID: <50C14B11.3070104@burnttofu.net> On 12/05/12 11:36, John Curran wrote: > Contrast this with RPKI, where ARIN's CA may be depended upon by many > parties which otherwise have no relationship with ARIN, i.e. the business > partner who is harmed by RPKI usage by either their own failure or by > an upstream ISP not following best practices could easily be validating > routes via information obtained from ARIN's CA. If the business entered > the wrong AS in a ROA (but denies it after the fact), ARIN could face > significant legal action just proving that we performed correctly. Hence, > there is a real need for both system capabilities (in areas such as non- > repudiation) as well as appropriate legal protections. But why does the ISP, which is following best practices, have to indemnify ARIN? Why should that ISP get sued instead of ARIN, especially when ARIN ought to have the evidence to defend itself, as Chris notes? and: > Agreed. I am not at all worried about our performance or any fault on ARIN's part, > but that will not deter a multiyear litigation over proving exactly that fact. This is > why an indemnification is rather important, because it reduces the potential for > such litigation upfront, and hence why it is a standard component of many types > of service contracts including ISP and certificate providers. So, this is where my lack of legal experience is telling. How will my indemnifying ARIN reduce the potential for such litigation upfront? It seems that it will reduce the proposal of ARIN being sued up front, but will increase the potential of me being sued. Or will the would be litigators say "Mike Sinatra doesn't have any money, but ARIN does, so let's sue them. Oh! But Mike Sinatra indemnified them so we have to sue him. But he doesn't have any money so it's not worth it. Curses!"? More seriously (and practically), having to indemnify ARIN is a huge obstacle to even testing RPKI, as the only way to generate a ROA and get the TAL is to indemnify ARIN. I now see David Farmer's response in arin-tech-discuss (sorry I missed it--October was kinda busy), and I think a useful compromise is to try to place an addendum to any pre-existing (L)RSAs. But if the addendum includes third-party indemnification, it's going to be an obstacle, if not a show-stopper. michael From jcurran at arin.net Thu Dec 6 20:58:30 2012 From: jcurran at arin.net (John Curran) Date: Fri, 7 Dec 2012 01:58:30 +0000 Subject: [arin-discuss] Question about the ARIN Relying Party Agreement - RPKI 'everyone must sign' and such... In-Reply-To: <50C14ABE.20609@burnttofu.net> References: <3D02AF5B-7305-4A3B-86C5-292A5B6BD8D2@corp.arin.net> <31B6D919-5B98-42E1-927C-CB1EC51739BB@arin.net> <2617B950-F76A-453C-9C41-697C1B36B246@arin.net> <50C14ABE.20609@burnttofu.net> Message-ID: <1DAF94A8-C6F7-4CE5-A137-94CE1B17F16B@arin.net> On Dec 6, 2012, at 8:47 PM, Michael Sinatra wrote: > > So, this is where my lack of legal experience is telling. How will my > indemnifying ARIN reduce the potential for such litigation upfront? It > seems that it will reduce the proposal of ARIN being sued up front, but > will increase the potential of me being sued. That's likely a question for your legal counsel. Just as noted earlier with many other service provider contracts, indemnification for your use of the service is a very common clause, as it puts the onus on the user of service to do so prudently. ARIN is not directing members to make use of RPKI, and some may easily come up with applications of the service which are not at all appropriate; we cannot offer RPKI services if we have to engage in a lengthy legal battle (when such applications go very bad) in order to extricate ARIN from such cases. Thanks, /John John Curran President and CEO ARIN