[arin-ppml] RPKI Relying Agreement

[David Huberman]

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: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Michael Sinatra <michael+ppml at burnttofu.net>
Sent: Thursday, December 4, 2014 1:28:40 PM
To: John Curran
Cc: ARIN-PPML at arin.net
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 <michael+ppml at burnttofu.net> 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 (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.