Paul Thanks for taking the time to go through the draft. Addressing your comments:
On 23/09/14 04:06, Paul Hoffman wrote: > At the beginning of 2.1: For ZSKs, the issue for the zone > operator/signer is to ensure that any caching validator has access > to a particular signature that corresponds to a valid ZSK. "that > corresponds to" seem wrong here. The following may be more > accurate (or it might be wrong...): For ZSKs, the issue for the > zone operator/signer is to ensure that any caching validator has > access to a particular signature has access to the corresponding > valid ZSK. The text resulting from the emails from you and Niall O'Reilly: "For ZSKs, the issue for the zone operator/signer is to ensure that any caching validator which has access to a particular signature also has access to the corresponding valid ZSK." ...seems OK. We'll update that paragraph. > In 2.2, it says "It is important to note that this does not > preclude the development of key rollover logic"; I can't figure > out what "this" refers to. There are a bunch of things in the two > preceding paragraphs that it might mean. How about: "It is important to note that the need to interact with the parent does not preclude the development of key rollover logic;" > The introduction to 3.1 caught me, and I can't figure out whether > or not it is right. A DNSSEC key contributes two pieces of > information to the validation process: the DNSKEY itself and the > data created from it. In the case of the validation of an RR, the > data created from the DNSKEY is the RRSIG. Where there is a need > to validate a chain or trust, the data created from the DNSKEY is > the DS. In this section, the term "associated data" refers to the > RRSIGs created from a DNSKEY when discussing a ZSK, or to the > DNSKEY's corresponding DS record when referring to a KSK. Is the > "associated data" for a KSK really just the DS? Shouldn't any > RRSIG over the ZSK that was created by the DSKEY also be > "associated data"? I'm not clear what you mean by "any RRSIG over the ZSK that was created by the DSKEY". Do you mean the RRSIG over the DNSKEY RRset created by the KSK in question? If so, I take the point that the KSK's associated data can be regarded as both a DS record and the RRSIG over the DNSKEY RRset and so as written, it is not completely clear. I think there are two things relevant for this paragraph: * The draft doesn't concern itself with the validation of the DNSKEY RRset (i.e. that it is signed by a valid KSK). So when talking about the ZSK, it is taken as read the ZSK has been validated by a KSK. In the case of a KSK, the assumption is that the KSK comes from a DNSKEY RRset signed by itself, and so the draft only concerns itself with the validation of the KSK against the DS. * In virtually all cases, the KSK and the DNSKEY signature created by it are added to and removed from the zone together. They also travel together - you always get the RRSIG when you retrieve the DNSKEY. The term "associated data" is really trying to capture the idea that in some cases the pieces of data required for a validation are obtained separately, perhaps at different times. I'm not sure whether the above two points need to be clearly spelt out in the draft or whether they are clear from the context of the discussion. If the latter, modifying the paragraph to: "A DNSSEC key requires two pieces of information to perform validation: the DNSKEY itself and associated data created from it. In the case of the validation of an RR, the data associated with the ZSK is the RRSIG. Where there is a need to validate a chain or trust, the associated data is the DS." ... may address your point. If not, an additional subsection in section 3 will be required to make the points listed above. > Also in 3.1: Ready The DNSKEY or its associated data have > been published for long enough to guarantee that any previous > versions of the DNSKEY and/or associated data have expired from > caches. This is discussing a new key. What is the "previous > version"? How about rewording it as: "The DNSKEY or its associated data have been published for long enough to guarantee that copies of the key(s) it is replacing (or associated data related to that key) have expired from caches." > Section 3.3.5 is really important to some readers, but it could > easily be lost. There should be a sentence near the end of 1.1 > that says "Note that introduction of first keys is different than > rolling a key; see Section 3.3.5 for more information about that > topic." Accepted. > Section 6 really should be Section 1.4. The paragraphs will make > it much easier for someone reading the document who exclaims (to > no one in particular) "they didn't consider X" as they are reading > the meat of the document to understand that the authors probably > did think about it, but chose to not include it. Fair point - accepted. Stephen _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
