On Mon, Nov 14, 2011 at 7:02 PM, Danny McPherson <da...@tcb.net> wrote: > > On Nov 14, 2011, at 6:47 PM, Rob Austein wrote: > >> Layers 8+ are mostly out of scope for this list, so let me just say >> that I am really hoping that IANA and the RIRs will get their >> collective act together and issue a single TA before this becomes a >> serious problem. They say that they intend to do so. As somebody (KC >> Claffy?) said a few years ago, relying parties should not have to sort >> out this mess, that's what the industry pays the RIRs to do. For the >> moment I'm willing to take the RIRs' word that they intend to do their >> job and just need a bit more time. YMMV. > > Until then (or even after in the event of a CA compromise), it's a > technical issue and the capability for RPs to determine who holds > what resources, or at least to constrain who they trust with what > resources, and intersect that with the LTA 'federation' issue is very > much an operational issue.
This is back to your (danny) point about: If someone[1] removes a Resource Certification (ROA, for instance) and that resource is actually critical[2] (or in use), all parties between the resource (server) and the service-requestor (user) are bound to need to know that the resource is still there, and valid. These parties all need to populate their LTA (Local Trust Anchor) with the right certification data. This seems like it will be messy, telling everyone via some phone-tree, and potentially confusing. On top of that if the resource is then re-certified (to the same or different end entity) how do the intermediate parties know which is the 'right' thing to do? -chris [1]: This is the nominal 'black helicopters' problem, also seen today via ICE or PROTECT-IP [2]: The netblock, for instance, for the .cx ccTLD (presuming that .cx is doing/permitting-some-actions that a third party finds objectionable) b: I made up the example, and the 2 'black helicopter' examples are certainly USA-centric, we could make up many more, but ... that's not horribly relevant. The problem could also be triggered by someone mistakenly missing their payment window to the RIR. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
