On 16 mrt 2009, at 16:34, Paul Hoffman wrote:
It feels like a lot of DNSSEC questions these days are being answered by "that's covered if you use RFC 5011". If so, then maybe proper use of RFC 5011 (such as when to assume that a zone is *really* being signed, not just for practice) should be part of draft-ietf-dnsop-rfc4641bis.
I think you have a point. I can imagine that such section would be about putting trust in a trust-anchor and the considerations that apply there. Shooting from the hip here are some considerations:
- When to trust a trust anchor:* whenever the zone-owner declares that a key is ready to be used as trust-anchor and * whenever you, as validator administrator, are satisfied that the rollover procedure is documented clearly enough and you are confident you can track the rollovers
- When not to trust a trust anchor:* when a key appears in a zone and there is no trusted out-of-band communication that
such key is in production.
- Cases where transitive trust may work:
* when a trusted third party validates the key-zone binding, the
production
readiness, and tracks the keys. (ITAR)
* when copying zone data from a parental zone to which you have a
DNS trust relation.
I can see rare cases why you would want to establish a trust-
anchor in the middle of
a chain of trust that is in place. But if you follow this route
I'm not sure about if
there is a fate sharing argument that renders this sort of
configuration useless.
Obvious missing points? I've added this as open issue: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration --Olaf
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
