Matthjis, On Wed, 27 Jul 2011 18:03:30 +0200 (CEST), Matthijs Mekking <matth...@nlnetlabs.nl> said:
> On Wed, 27 Jul 2011, Alexander Gall wrote: >>> I don't understand which corner case this is supposed to cover. The >>> relevant section of RFC4035 quoted in the draft says >>> >>> There MUST be an RRSIG for each RRset using at least one DNSKEY of >>> each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset >>> itself MUST be signed by each algorithm appearing in the DS RRset >>> located at the delegating parent (if any). >>> >>> My understanding of this is that there is no requirement for the >>> existence of the signature over the DNSKEY RRset by K_2 until the end >>> of the step "new DNSKEY", because up to that point, the DS doesn't >>> refer to algorithm 2 yet. > My understanding of this paragraph is that there MUST be an RRSIG for > each RRset using at least one key of each algorithm in the DNSKEY RRset. > So that includes the DNSKEY RRset itself. *In addition*, the DNSKEY RRset > MUST be signed with the algorithms appearing in the DS RRset. Ok, so the snippet from 4035 alone appears to be ambigous to me. Is this clarified somewhere? > The corner case tries to make clear that a DNSKEY RRset can be > treated as part of the chain of trust, but also can be treated as zone > content. In the latter case you want to make sure that the signatures > of the new algorithm are propagated before introducing the new DNSKEY. I sort of understand the intention. But how *exactly* would it work? Note that the "pre-published" signature in zone SOA_1 will differ from that in zone SOA_2, because the DNSKEY RRset is not the same (this is different from pre-published signatures by the ZSK, because the RRsets themselves do not change). Suppose a validator happens to fetch the DNSKEY RRset from SOA_2 but still has RRSIG_K_2(DNSKEY) from SOA_1 in its cache. I guess this is one of the corner cases, right? However, wouldn't the validator be unable to verify that RRSIG because it covers a different DNSKEY RRset (the one without Z_2 and K_2)? It seems like to cover this case, you'd have to pre-publish the signature of the DNSKEY RRset that will appear in SOA_2. It's not obvious to me whether this doesn't create problems of its own. -- Alex _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
