On Sat, Jul 26, 2008 at 12:21:47PM -0400, Brian Dickson wrote:
> Stephane Bortzmeyer wrote:
> >On Sat, Jul 26, 2008 at 01:14:08AM +0200,
> > Roy Arends wrote
> > a message of 28 lines which said:
> >
> >
> >>When a validator has a trust anchor configured for root, it _expects_
> >>signatures for root.
> >>

> >
> >Which means there is no way back? If we sign ".fr", and people start
> >to configure the trust anchor for ".fr" in their validating resolvers,
> >we can no longer revert to the original, non-signed, system, should
> >problems occur?
> >
> >Am I correct? AFAIK, DNSSEC has no way to express policies (in a
> >RFC5016-like way) such as "should be signed".
> >

>
> You are correct.
>
> However, if the root was signed, there would be no need for having
> separate trust anchors configured
> for a signed .fr.


presuming facts not in evidence.
how are you to -know- that the root has the "right" DS for .FR?
most operational keystores will have at least four keys and likely
operational practice will be, roughly 3 per relevant org; the current,
the immediate past, and the next future key.

as a grad student, I will likely have keys from (at least) these places:

my school, the parent org (.EDU), the root, the LIR, the RIR.

that looks like 15 keys...


> And, this would mean that turning on or off the status of "is .fr
> signed?" could be handed from the root
> zone, allowing *relative* ease in backing out the signing of any TLD. No
> configuration changes would
> be needed by the operators of validating resolvers.
>
> (IMHO, in addition to signing the root zone, there need to be changes to
> the speed with which changes
> of a technical nature can be made, once the technical administration of
> a TLD has been authoritatively
> and contractually delegated to an entity. Those include changes to A and
> AAAA glue records, and
> addition/removal of DNSSEC signatures (and thus the
> "signed"/"not-signed" status).)
>
> Brian
>
> --
> 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:


--
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: