Noel Chiappa wrote:
> From: Christian Vogt <christian.vogt@nomadiclab.com>
> Ah, you are using global trust anchors. That will work, yes.
> One question, though: Who will be the entity in charge of operating a
> root CDR (and hence of signing ID/locator mappings)? This entity will
> be in a very powerful position
Well, to start with, there is no single entity which signs bindings for the
entire namespace - as I mentioned, we would probably want to split the
namespace up into zones (e.g. maybe /8's), and have a separate key (and
signing entity) for each zone, in part so that no single break-in can
compromise (and require re-signing of) bindings across the entire nameapace.
Your question raises a separate issue, though, which is that in that scheme
as I describd it, each portion of the namespace would indeed have one entity
which is in charge of signing bindings for it, and yes, that would be a
powerful position.
What DNSSEC does, is sign *delegations*, until the leaf nodes, who sign their own data.
The proper analog for EID->RLOC binding mappings would be: DNS root zone signs delegation to appropriate TLD operator (e.g. arpa). TLD operator signs delegations to RIRs RIRs sign delegations to LIRs LIRs sign delegations to customers[and further delegations are certainly possible to essentially arbitrary depth].
In each case, the zone is self-signed as well as signed by the parent.Since in no case is the data itself signed by anyone other than the delegatee, the risk is limited to key data scoped appropriately, where key rollover is handled by the parent. Only root key rollover results in "flag day" issues,
something already well known for the whole trust anchor model. Brian Dickson -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg