ZSK rollover weirdness

[Casey Deccio]

On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt <each at isc.org> wrote:

> The revoke bit has no defined meaning for a ZSK.


While it's true the revoke bit really has no use for a true ZSK (i.e., a
key where there's another key, a KSK, that is used to authenticate it), RFC
5011 doesn't distinguish based on either signing roles (ZSK/KSK) or
presence of the SEP bit [1]:

   A key is considered revoked when the resolver sees the key in a
   self-signed RRSet and the key has the REVOKE bit (see Section 7
<http://tools.ietf.org/html/rfc5011#section-7>
   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
   NOT use this key as a trust anchor or for any other purpose except to
   validate the RRSIG it signed over the DNSKEY RRSet specifically for
   the purpose of validating the revocation.

In other words, if the revoke bit is set, that key is no good for signing
anything other than itself, which is why DNSViz complains about it.  And
just to clarify, the use of the SEP bit is purely an administrative/user
convention or "hint", but is not considered during validation [2,3].  Thus
whether a key is action as a "ZSK" or a "KSK" really depends on how they
are used.

Casey

[1] http://tools.ietf.org/html/rfc5011#section-2.1
[2] http://tools.ietf.org/html/rfc6840#section-6.2
[3] http://tools.ietf.org/html/rfc4034#section-2.1.1


> It's used for updating
> trust anchors via RFC 5011. The code allows you to set it (just as it
> allows you to use a ZSK as a KSK), but I don't recommend it.
>
> Unless there are resolvers that have managed-key trust anchors configured
> for ksu.edu, you shouldn't bother with the revoke bit for your KSK either.
>
> --
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130906/40ca280d/attachment.html>