How are people implementing hold-down in RFC 5011?

Greetings. In reading RFC 5011 more carefully, I am finding that some of the wording is confusing (possibly just to me). I have a few questions for people who have implemented it in systems, but also want to hear from the greater DNS community.

Section 2.2 says:

   Assume two trust point keys A and B.  Assume that B has been
   compromised.  An attacker could generate and add a new trust anchor
   key C (by adding C to the DNSKEY RRSet and signing it with B), and
   then invalidate the compromised key.  This would result in both the
   attacker and owner being able to sign data in the zone and have it
   accepted as valid by resolvers.

I am assuming that "invalidate" means "revoke". Pictorially, I think this means the following progression in time:
   1: Owner's zone: A signs (A B)
   2: Attacker's zone: B signs (A Br C)
(Here, "Br" means "B with the REVOKE bit set".)

Immediately after the relying party has seen (2), B can never be trusted again, even while they are waiting for the hold-down timer for adding C.

Later in Section 2.2, it says:

   In the given example, the zone owner can recover from a compromise by
   revoking B and adding a new key D and signing the DNSKEY RRSet with
   both A and B.

The time progression here sounds like:
   1: Owner's zone: A signs (A B)
   2a: Attacker's zone: B signs (A Br C)
   2b: Owner's zone: B signs (Br) and A signs (A D) and B signs (A D)
2a happens before 2b because that is how the owner discovers that B was compromised.

I don't understand why B signs (A D) in 2b. B is already untrusted to anyone who saw 2a, and is untrusted by anyone looking at all of 2b. These instructions seem to be saying "put a signature into the zone that cannot be validated". I would think that 2b should just be "B signs (Br) and A signs (A D)", but that's not what the RFC says.

So: has anyone implemented what the RFC says? If so, did you try it with some validating resolvers? What were the results?

Or: am I completely misreading something in this section?

--Paul Hoffman
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext