-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also, RFC 5011 may adapt key rollover practices. In short this means that when a key may be removed because it is considered dead, it should stay in the zone for one RRSIG TTL more with its REVOKED bit set before removing it from the zone. This way, rfc5011 enabled resolvers can update their trust anchors in-band.
Matthijs Olaf Kolkman schreef: > > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBScKFgg8yVCPsQCW5AQJnCQf/QLbLjp85Zp7zQPvb9z8KGdeCz1O52rGz boMljfuOcnvk9iZy/pZNnbyUT0msMX64FryiS4CGXNTZ/Qeen8+87KqTSI85/Wpo 2r/vebDrZU2MUNIbgYc/4Jxi0vtutsBrpT3Vvop8TpxL5DcfuMs8O1edbDcC/dw5 AFkzb1a1SF3GRxjnJTWzv3KsYHABGCfyT9d25bRc02iJgXjZqwxrpI2fDPG+Dog0 PnQ1Mc15vbQYO1g7PFBHv08qyAfuqfuUXGqy7aUB+c+SCZcveHRe4/wEVMw6mGtv UCJHzNldYcDJrhwyN9HLbsVKxTDf+W1Y/5TSNk9iCVELvMtOpziELg== =E+dk -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
