-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 Jul 2011, Alexander Gall wrote:
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?
Perhaps draft-ietf-dnsext-dnssec-bis-updates can add that clarification,
if appropriate.
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).
It's about pre-publishing the algorithm. But I now see what you mean and
I think you are right. The corner case does not actually need these
special considerations. The algorithm rollover described as it is now is
not wrong, it just adds a redundant signature in the 'new RRSIGs' step.
Thanks for the catch.
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.
Can this even happen? It is my understanding that if you have to fetch a
new copy of the DNSKEY RRset, you automatically would get the
corresponding signatures.
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)?
If a validator would be able to get in this situation, yes. But I don't
think this is possible.
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.
That sounds very complex to me too.
I think in order to fix the document, the text about the corner case
should be removed, as well as the redundant signature in the rollover
figure.
Best regards,
Matthijs
--
Alex
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJOMZx7AAoJEA8yVCPsQCW5HdoIAI/z7o/0A3+PYMifE/kakdYE
LdM2080SQ590kTHXWKzWUdBGL8GJKmqGdDVGNbTn0W0njK9gEHDx4A1FQHr4EPj9
Ze464ZbGmkcyGKxaqvVVAYvj6JI+/spXH0UZNvQOCT73NZYL/IHAJeRx0xXjF1oq
R8g4Y7gepN424092bET91m7BJDBYzhQ5spBAlT6zHR8XvKnTHZM02gx8Zp95CEAq
BuxWd7ZJVE+Du1nimaeCmvK1DgWUCv6+4m81ICtXFECo+ER3ROmiGUFGDcsso6qa
W5s8lm4PKphr0KIg5pRsOjn5NLnn2XDqJ5ZEDZyimDhj4xeFf7JdCg2pUOE3XNg=
=9XvF
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
