At 20:13 +0200 4/22/09, Peter Koch wrote:
this is to initiate a working group last call on
"DNSSEC Trust Anchor Configuration and Maintenance"
draft-ietf-dnsop-dnssec-trust-anchor-03.txt
ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy access to
diffs and such under
<http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03>.
I keep forgetting this bit of document jockeying - can an Informational use
RFC 2119 terms in a normative way?
...
#3. Trust Anchor Priming
...
# 3. Verify that the DNSKEY RR corresponding to the configured trust
# anchor (i.e., the DNSKEY whose hash is configured) appears in the
# DNSKEY RRSet and that this DNSKEY RR has the Zone Key Flag
# (DNSKEY RDATA bit 7) set. (This bit only indicates that the
# DNSKEY is allowed to sign the zone. This DNSKEY may or not be a
# zone signing key.)
Last sentence? - "This DNSKEY might not be a zone a zone signing key.")
But I'm not sure what is meant. At first the paragraph reads - make
sure the Zone Key Flag is set and later says it "may or [may] not be
a zone signing key."
Do you mean that "this" key could be a "key signing key?"
# 4. Verify that the DNSKEY RRSet is signed by one of the DNSKEYs
# found in the previous step, i.e., that there exists a valid RRSIG
# (cryptographically and temporally) for the DNSKEY RRSet generated
# with the private key corresponding to the DNSKEY found in the
# previous step.
And here, are you saying that "this DNSKEY RR"'s private companion
has to sign the key set for all this to work? In step three you
refer to a singular ("this") key, in step four it is plural ("is
signed by one of the").
...
# For this reason, old trust anchors SHOULD be removed from a
# validating resolver's trust anchor list soon after the corresponding
# keys are no longer used by the zone, as described in RFC 5011
# [RFC5011].
Recommend that the priming be done often enough to capture revoked
DNSKEY RR's - so that the zone doens't have to keep them indefinitely.
# 4. Trust Anchor Maintenance
#
# Trust anchors correspond to zones' key signing keys and these keys do
<keeping the terminology clean>
Trust anchors *could* be zone signing keys. Still I think you want
this here - SEPs? Is that what is meant?
(RFC 4034:
2.1.1. The Flags Field
...
Bit 15 of the Flags field is the Secure Entry Point flag, described
in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
key intended for use as a secure entry point. This flag is only
)
# 5. Security considerations
#
# This document proposes a standard format for documenting DNSSEC trust
# anchors.
I didn't see a standard format (a la a zone file). Just "use the DS
fields." Perhaps I was expecting examples and such.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Getting everything you want is easy if you don't want much.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
