[dnssec-deployment] TAR discussion from SF and resulting definitions: take 2
paul at xelerance.com
Tue Apr 28 19:07:59 EDT 2009
On Tue, 28 Apr 2009, Wes Hardaker wrote:
> PW> This is not entirely correct. Only when seeing the revoke bit can we
> PW> transfer the trust anchor from the revoked key to the other KSK that is
> PW> signed by the revoked key. Before the revoke bit key appears, we don't
> PW> know the purpose of the second KSK. So the "should not be used by any
> PW> party" text is not entirely correct. This is because we only have a "retire"
> PW> bit and not a "successor" bit. I would say:
> I agree that the wording could use some improvement, but I don't agree
> at all with your statements above. The revoke bit in no way indicates
> that you should trust the successor key and "transfer trust". If you
> reread 5011 you'll find the two mechanisms (adding a trust anchor and
> removing a trust anchor) are intentionally independent. After noticing
> a new key, and waiting the proper hold down time, verifying it
> cryptographically, etc... you add it as a trust anchor. You certainly
> may have two valid trust anchors at that point.
I was wrong indeed. Thanks for pointing it out.
> So... changing my wording a touch, how does this sound:
> A key that has been designated as revoked and should not be used by
> any party except to verify the authenticity of the
> revocation. Normally this would be a published DNSKEY with the
> RFC5011 revoke bit set.
> PW> I then got completely lost in in the zillion different TARs. I feel
> PW> that I should probably go home in my PATVOMAHA [*]
> I don't blame you. The 3 hour discussion held at the IETF pointed
I am not sure defining every possible instance will help in that discussion.
I for sure won't remember to use the 20 different kind of tar nouns.
More information about the Dnssec-deployment