Sam has been unable to post this on namedroppers himself, so he asked me
to forward this message.
Olafur
Date: Tue, 22 Jul 2003 18:10:28 -0400 (EDT)
From: Sam Weiler <weiler@tislabs.com>
To: namedroppers@ops.ietf.org
Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys
in a security-aware resolver (fwd)
[I've seen this bounce twice. If it actually got through and you're
seeing a duplicate, my apologies.]
> Q-12: Should support for configuring multiple trusted public keys in a
> security-aware resolver be a MUST rather than a SHOULD?
A security aware resolver is unlikely to be very useful without this
capability, but does omiting it negatively impact the protocol? It
doesn't affect the on-the-wire bits. "Constraining users" doesn't
justify a MUST. If, however, having only one configured key would
effectively prevent key rollover (as in, rollover of the one true root
key), then we need to be concerned.
Imagine this scenario: the root wants to roll its key. Having
clients with only one configurable key mean that the root must sign
with both keys during the transition window. If all clients can
configure multiple keys, they can add the new one before it's actually
in use, the root can make the change all at once, and everyone who has
updated their keys keeps on going, removing the old keys at their
leisure. Is it valuable for the root (or any zone who's key will be
configured in end clients) to be able to roll over all at once? With
the layer of indirection (SEP/ZSK) introduced by DS, it's not
manadatory -- it's tractable to sign a KEYset with multiple KEYs for
an extended time. Except that those extra signatures may make packets
big. With 2535, if the secure entry point was, say, .com, then
keeping the whole zone signed with multiple keys would not be
tractable.
Summary: I don't see a jutification for a MUST. Or even a SHOULD.
This is implementation advice, not protocol requirement. It should be
there, but it's not critical to interoperability.
-- Sam
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>