<html><head></head><body>If ARIN's legal counsel feels there is no way to avoid requiring *explicit* legal agreement prior to using RPKI data (as distinct from *publishing* RPKI data) then I would suggest that there is a clear community consensus just based on what I've heard here and at ARIN 34.<br>
<br>
Unfortunately, the dialog between ARIN and its community boils down to "the business and legal climate in the United States is too hostile to permit easy and widespread use of RPKI data".<br>
<br>
If ARIN can't find a way around that problem, perhaps they should consider reincorporating somewhere more conducive to business... (Maybe even in a country where the government is the only 3rd-party actor you have to worry about?)<br>
<br>
>From a Canadian standpoint, this entire argument is ridiculous... (So far, anyway. Sadly, we're catching up.)<br>
<br>
<pet-peeve>Either way, this is an example of what I said previously about US-centrism being a problem.</horse><br>
<br>
-Adam Thompson<br><br><div class="gmail_quote">On December 4, 2014 3:37:56 PM CST, David Huberman <David.Huberman@microsoft.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">It's a good email Michael. The bottom line (as I see it) is the ARIN Board is saying "you must do it this way" and the community is saying "no". Nobody is winning here. I urge the Board to reconsider its position, as I believe the RIRs are the right parties to hold the trust anchor for route origination mechanisms, so we need to work together (Board and operators community) to find an acceptable middle ground.<br /><br />David R Huberman<br />Microsoft Corporation<br />Principal, Global IP Addressing<br /><br /><hr /><br />From: arin-ppml-bounces@arin.net <arin-ppml-bounces@arin.net> on behalf of Michael Sinatra <michael+ppml@burnttofu.net><br />Sent: Thursday, December 4, 2014 1:28:40 PM<br />To: John Curran<br />Cc: ARIN-PPML@arin.net<br />Subject: Re: [arin-ppml] RPKI Relying Agreement<br /><br />On 12/04/2014 10:01, John Curran wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf;
padding-left: 1ex;"> On Dec 4, 2014, at 12:25 PM, Michael Sinatra <michael+ppml@burnttofu.net> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><br /> On 12/04/2014 07:59, John Curran wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> ...<br /> Actually, the terms regarding indemnification and warrant disclaimer are nearly<br /> identical to that contained in the other RIR's RPKI agreements; are those also<br /> problematic, or is the difficultly that principally that ARIN agreeing to the<br /> terms explicit rather than implicit?<br /></blockquote><br /> I disagree. The only terms I was able to find were APNIC's and they<br /> only referred to "Certificates issued by APNIC," not a TAL. So I really<br /> don't think there is another TAL RPA out there that's anything like ARIN's.<br /></blockquote><br /> Michae
l -<br
/><br /> APNIC "CA Terms and Conditions" states "The recipient of any digital certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate."<br /><br /> Relying parties (even if not subscribers to the CA) are any<br /> entities that act in reliance on certificates in the CA, so<br /> the terms and conditions would be applicable. How they go<br /> about obtaining the TAL doesn't change the indemnification<br /> asserted by APNIC.<br /></blockquote><br />Just for clarification, so that folks understand what we're talking<br />about, a TAL, or trust-anchor locator, is basically an rsync URI<br />followed by a public key (so that the trust anchor cert can be<br />validated). It is not a certificate. So, it would seem analogous to an<br />https URL combined with the CA public keys that are bundled with most<br />web browsers, except that it doesn't include the
full CA
certificate.<br /><br />ARIN requires the click-through signature just to acquire that URI plus<br />public key, in order to allow someone to validate those resources<br />located in the ARIN region. Again, this is different from what APNIC<br />requires.<br /><br />And the validation process that John states is covered by the APNIC<br />agreement is very close to the same process a web browser uses to<br />validate an SSL/TLS certificate. So I still have a hard time believing<br />that it is APNIC's intention that I am supposed to indemnify them every<br />time I validate a web server certificate that is issued by them. On a<br />related note, I can download APNIC's root cert from APNIC's website<br />without even looking at their terms and conditions.<br /><br />The indemnification clause in question predates the offering of resource<br />certification services by APNIC, so again, I question the intent of this<br />clause. This is in contrast to ARIN's RPA, which define
s the
relying<br />party specifically in relation to the use of the online resource<br />certification PKI and is careful to include in its scope not only<br />receiving a certificate, but using any information located in that<br />certificate. To me, what ARIN is specifying is very different than what<br />APNIC is specifying.<br /><br />The issue is not to say that somewhere, somehow, someone might make the<br />argument that resource certification in the APNIC region falls under<br />some obscure indemnity clause. The issue is that what ARIN is making me<br />agree to is not "nearly identical" to what APNIC, or any other RIR,<br />appears to be doing.<br /><br />All of that said, I really do understand ARIN's risk perspective, and I<br />appreciate John's willingness to spell that out. I wish there were a<br />legal framework that said "everyone is responsible for their own<br />screw-ups and needs to follow best practices to defend themselves<br />against the screw-ups of ot
hers."
Unfortunately the current framework<br />seems to create incentives for non-deployment of RPKI in the ARIN<br />region, and the proof is pretty much in the pudding.<br /><br />michael<br /><br />PS. Sorry for the long email. I'll refrain from further posts to this<br />thread.<br /><br /><hr /><br />PPML<br />You are receiving this message because you are subscribed to<br />the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<br />Unsubscribe or manage your mailing list subscription at:<br /><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br />Please contact info@arin.net if you experience any issues.<br /><hr /><br />PPML<br />You are receiving this message because you are subscribed to<br />the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<br />Unsubscribe or manage your mailing list subscription at:<br /><a
href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br />Please contact info@arin.net if you experience any issues.<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>