<div dir="ltr">On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt <span dir="ltr"><<a href="mailto:each@isc.org" target="_blank">each@isc.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The revoke bit has no defined meaning for a ZSK.</blockquote><div><br>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]:<br>
<pre class="">   A key is considered revoked when the resolver sees the key in a
   self-signed RRSet and the key has the REVOKE bit (see <a href="http://tools.ietf.org/html/rfc5011#section-7">Section 7</a>
   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.<br></pre>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.<br>
<br></div><div>Casey<br><br>[1] <a href="http://tools.ietf.org/html/rfc5011#section-2.1">http://tools.ietf.org/html/rfc5011#section-2.1</a><br>[2] <a href="http://tools.ietf.org/html/rfc6840#section-6.2">http://tools.ietf.org/html/rfc6840#section-6.2</a><br>
[3] <a href="http://tools.ietf.org/html/rfc4034#section-2.1.1">http://tools.ietf.org/html/rfc4034#section-2.1.1</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 It's used for updating<br>
trust anchors via RFC 5011. The code allows you to set it (just as it<br>
allows you to use a ZSK as a KSK), but I don't recommend it.<br>
<br>
Unless there are resolvers that have managed-key trust anchors configured<br>
for <a href="http://ksu.edu" target="_blank">ksu.edu</a>, you shouldn't bother with the revoke bit for your KSK either.<br>
<br>
--<br>
Evan Hunt -- <a href="mailto:each@isc.org">each@isc.org</a><br>
Internet Systems Consortium, Inc.<br>
<div class=""><div class="h5">_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</div></div></blockquote></div><br></div></div>