[dnssec-deployment] TAR discussion from SF and resulting definitions: take 2

[Paul Wouters]

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.

Okay.

> 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.

Paul