At 14:45 22/04/2009, Edward Lewis wrote:
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?"
We are trying to say that the key can be both KSK and ZSK but does not
have to be.
How about: "this DNSKEY might also be a zone 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").
you are right step 3 should be plural as well.
...
# 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.
Well RFC5011 requires you scan at least once a month, and recommends higher
frequency, is that sufficient?
# 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?
Same as above KSK and ZSK can be one key. There is no requirement that
a KSK have the SEP bit set only a recommendation.
(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.
We assumed (possibly incorrectly) that having a reference was sufficient.
thanks for your comments
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
