On Sep 25, 2014, at 5:38 AM, Stephen Morris <[email protected]> wrote:
>> 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;" Yes, great. (That was not my first expansion of "this", FWIW.) >> 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. Yes, exactly that. "or to the DNSKEY's corresponding DS record when referring to a KSK" actually limits it to the DS record. > 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. They were not clear to me. > 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. The stuff above makes it clearer, but readers will will still need to do some logic in their heads with it. However, given that this is more of an operational document, you don't really need to lay everything out. The modification is probably fine on its own. >> 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." Yep, fine. Thanks! --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
