On 1 Feb 2017, at 4:01 AM, Job Snijders <[email protected]<mailto:[email protected]>> wrote: I am certain that an appropriate (and equally short) wget command could suffice technically for installing ARIN’s TAL, but including such in a script (or including the TAL directly in the source code repository) would deprive parties of the ability to fully consider and accept the responsibilities involved.
Correct. Thank you for this summary. Your summary narrows it down to exactly the point of friction. Questions that come to mind: are the responsibilities as outlined by the RPA proportional to the goals the RPA is intended to achieve? Should any responsibilities be associated with the distribution of cryptographic public keys? To me DNSSEC seems an apt comparison. Job - The typical relying parties “usage” of certificates in DNSSEC is heavily proscribed by both protocol and implementation, and occurs with only nominal configuration choices on behalf of the relying party. Both the maturity of DNSSEC and deployment model greatly minimize the potential for misconfiguration on behalf of a relying party, with the result being that misconfiguration by zone administrators is a much more common occurrence and one whose impact is limited to but their own domain (reference RFC 7646 for more detail on same and thus the desire for locally administered negative trust anchors to address such circumstances...) Even when a DNSSEC validation error occurs, there remains the potential for self-help on behalf of end users (via the option to switch to a non-validating resolver.) Contrast this to RPKI, wherein the introduction of origin validation into an ISP’s routing architecture has many operational considerations, and inherently includes the potential to readily impact the ISP's primary business under anything less than carefully planned and executed BGP origin validation deployment efforts. While I’m am certain that everyone deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable workarounds by the impacted customers) inherently means the potential for business impact is greater than exists with deployment of DNSEC validation by ISPs – i.e. while I do believe that your comparison to DNSSEC is directionally correct, it fails overall due to the very real and significant difference in the magnitude of potential business impact to the relying party. /John John Curran President and CEO ARIN
_______________________________________________ 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.
