On Mon, Nov 14, 2011 at 10:57 PM, Danny McPherson <[email protected]> wrote: > > On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote: > >> 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? > > Agreed.. It's critical to highlight that LTA doesn't fix anything here > unless this is accommodated by all parties in the transaction path. >
in one sense, LTA is meant to certify resources local to the ASN (or set of ASNs which use the LTA, of course). It could be to cerify 'blackhole' routes, or RFC1918-like space. in another it's been bent for the 'stop the black-helicopters' problem (or the less controversal: 'Joe forgot to pay ARIN' case). So far your comments, I think, are about this use-case. > Furthermore, because CAs can be compromised (as we've seen with > many CAs whose @day_job IS security), and today anyone in your TAL also, we ought to be clear that the 'CA' is really one 'CA' at the root, we hope. which is both good and bad... > list can assert authority for any resources (as many are currently doing > currently), without the ability to filter this or scope it in some manner it > could be really problematic. agreed, can we only have one root CA please? :) Having more than 1 is just asinine. (imho) -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
