Matthijs Mekking wrote:
-----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.
This is more about use policy than anything else.
By the way since I personally coined the term "Trust Anchor" in PKIX
towards the late-1990's and got hammered by Dr. Kent for it, maybe I
should get to tell you what it means... Trust anchors by pure definition
are reliable points of reference which intended to make the content they
anchor portable, that is to say comparable in a like manner to other
like-anchored content. That said, a timestamp of any number of types can
be a trust-anchor as can a token created through some form of
cryptographic process.
Scary thought that eh?
Todd Glassey
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
