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.
David R Huberman Microsoft Corporation Principal, Global IP Addressing ________________________________________ From: [email protected] <[email protected]> on behalf of Michael Sinatra <[email protected]> Sent: Thursday, December 4, 2014 1:28:40 PM To: John Curran Cc: [email protected] Subject: Re: [arin-ppml] RPKI Relying Agreement On 12/04/2014 10:01, John Curran wrote: > On Dec 4, 2014, at 12:25 PM, Michael Sinatra <[email protected]> > wrote: >> >> On 12/04/2014 07:59, John Curran wrote: >>> ... >>> Actually, the terms regarding indemnification and warrant disclaimer are >>> nearly >>> identical to that contained in the other RIR's RPKI agreements; are those >>> also >>> problematic, or is the difficultly that principally that ARIN agreeing to >>> the >>> terms explicit rather than implicit? >> >> I disagree. The only terms I was able to find were APNIC's and they >> only referred to "Certificates issued by APNIC," not a TAL. So I really >> don't think there is another TAL RPA out there that's anything like ARIN's. > > Michael - > > 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." > > Relying parties (even if not subscribers to the CA) are any > entities that act in reliance on certificates in the CA, so > the terms and conditions would be applicable. How they go > about obtaining the TAL doesn't change the indemnification > asserted by APNIC. Just for clarification, so that folks understand what we're talking about, a TAL, or trust-anchor locator, is basically an rsync URI followed by a public key (so that the trust anchor cert can be validated). It is not a certificate. So, it would seem analogous to an https URL combined with the CA public keys that are bundled with most web browsers, except that it doesn't include the full CA certificate. ARIN requires the click-through signature just to acquire that URI plus public key, in order to allow someone to validate those resources located in the ARIN region. Again, this is different from what APNIC requires. And the validation process that John states is covered by the APNIC agreement is very close to the same process a web browser uses to validate an SSL/TLS certificate. So I still have a hard time believing that it is APNIC's intention that I am supposed to indemnify them every time I validate a web server certificate that is issued by them. On a related note, I can download APNIC's root cert from APNIC's website without even looking at their terms and conditions. The indemnification clause in question predates the offering of resource certification services by APNIC, so again, I question the intent of this clause. This is in contrast to ARIN's RPA, which defines the relying party specifically in relation to the use of the online resource certification PKI and is careful to include in its scope not only receiving a certificate, but using any information located in that certificate. To me, what ARIN is specifying is very different than what APNIC is specifying. The issue is not to say that somewhere, somehow, someone might make the argument that resource certification in the APNIC region falls under some obscure indemnity clause. The issue is that what ARIN is making me agree to is not "nearly identical" to what APNIC, or any other RIR, appears to be doing. All of that said, I really do understand ARIN's risk perspective, and I appreciate John's willingness to spell that out. I wish there were a legal framework that said "everyone is responsible for their own screw-ups and needs to follow best practices to defend themselves against the screw-ups of others." Unfortunately the current framework seems to create incentives for non-deployment of RPKI in the ARIN region, and the proof is pretty much in the pudding. michael PS. Sorry for the long email. I'll refrain from further posts to this thread. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
