-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ondřej,
On 08/04/2010 04:45 PM, Ondřej Surý wrote: ... > This is just a follow up for the discussion in Maastrich on RFC5011 and > key algorithm rollovers. > > I thought of sending the text, but I have re-read the 5011 and it looks > more complicated :-(. I send text, but unfortunately my mail did not reach the dnsop mail list yet :( > Just a reminder: RFC4035 section 2.2 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). > > RFC5011 sections: > > 2.1. Revocation > > If you have a key A with alg1 and key B with alg2, you: > > a) cannot revoke any of the keys You can, you need temporary 'shadow' keys that have the same algorithms. So, introduce key A' with alg1 if you want the revoke A and introduce introduce key B' with alg2. Note: Key A' and B' will not be trust anchors, don't use the SEP bit on them. > b) we must define that revoked key as an exception to RFC4035 2.2 That's one way to solve the issue, but that changes the protocol. We can also describe how the rollover to a different algorithm should happen that fits in the current specification. > 2.2 Add Hold-Down > > Basically same situation. > > If you add key C with new algorithm, you need to immediately sign whole > zone with new algorithm regardless of the hold-down timer. The hold-down timer is meant for the resolver, the one who signs the zone does not need to take the hold-down timer into account. When you add a key C with a new algorithm, you already must have the signatures for it in your zone (just like 4641bis already describes) > 6.1 Adding a Trust Anchor > > The scenario is incorrect in step 4 and you need to follow the procedure > outlined in draft-ietf-dnsop-rfc4641bis-04.txt For clarification, if you do algorithm rollover. > 6.2 Deleting a Trust Anchor > > Is correct, but it still needs to follow the: When rereading, it's actually not: The operator (I am guessing the zone operator) should include the revoked 'A' in the RRset for at least the Maximum Zone TTL, not the hold-down timer. > - remove DNSKEY > - wait for DNSKEY TTL > - remove signatures > > after step 2. > > 6.3 Key Roll-over (and 6.4 and 6.5) > > If the 'C' has different algorithm then the step 2. and 4. are incorrect. Yes, because for step 2 you need to add the signatures for C. The whole scenario can imo actually not be narrowed down to the DNSKEY RRset, you need to take the whole zone into account. > 6.6 Trust Point Deletion > > Is incorrect. If the new key has different algorithm, you need to > publish DNSKEY first and only after it's there (and expired in caches) > you can update DS at parent. Yes. > > So it get's much more complicated. And you cannot revoke old-keys at > the same time you add new keys. > > Ondrej Not at the same time, but that is also true for regular key rollover (not switching algorithms). If 5011 is in place, algorithm rollover can easily be extended with one extra stage, that is, before removing the old key, revoke it. This requires a shadow key with the same algorithm that signs the whole zone. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWmptAAoJEA8yVCPsQCW5uj0H/0RB2hkqI3e0RPa/Ljlot4A3 BFVD0hedQ0o9lg5Z+Hxg1c+0mtW4SDsjVJ9o+HlRm8OSZzHWu5C3ekDRUe6Yku33 +m47805dOYzpr8dc37keakgZHfAootUpBTh5n1bo09QxMk4qgFRS/j3SjvoN08ds /iHrq4zi0G6gFmqPOY6Olk5HZYSS+eblV4GE4iHchi4kmYfnmpQNzQ5o/XrAzhiq 3i5nDUNSIxAtp3UydnITOjzgqIVEbZ0bHCKjYhYhu2MA99htAvNmXKun78Sk/6bG ++MVHqcHTmIDBKcWD3HMHVQk0shFUFWqdWO9ZFAj5Cqlx9+wwksD8UOHDmdl6Ts= =3U6E -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
