[Dnssec-deployment] root key - getting close

Matt Larson mlarson at verisign.com
Wed Jun 2 20:04:43 EDT 2010

On Wed, 02 Jun 2010, Chris Thompson wrote:
> The obscuring of the revoked KSK seems to have mucked things up:
> I suspect the key id was meant to remain 19452, but maybe their
> obscuring tool (which is meant to preserve key id) doesn't work
> properly with revoked DNSKEY records? It's possibly significant
> that adding the revoked (0x0080) bit to the flags increases the
> id by either 128 or 129 (see RFC 4034 Appendix B) and we have seen an 
> increase by 128 and then another by 129.
> Is anyone from ICANN or Verisign able to comment?

We have been concentrating our efforts on the ICANN-VeriSign exchange
of "key signing requests" and "signed key responses", and checking the
ZSK and KSK rollover procedures.  Unfortunately, we encountered a
corner case in the the "key blinding" code: it did not properly handle
the revoked bit.  First it didn't blind the revoked KSK, and then, as
you've observed, it did not calculate the proper key tag for the
revoked blinded key.

Today we updated and deployed new key-blinding code, and the latest
root zone, SOA serial 2010060201, now has proper key tags for all

On Wed, 02 Jun 2010, Casey Deccio wrote:
> But of the course the other issue of the "revoked" key not being self-signed
> still holds, possible related to the "obscuring" as you mentioned.

It only appeared that the key set is not signed with the revoked KSK
because of the key tag mismatch.  Indeed, for a 20-day period during a
KSK rollover period (which is where we are in now), both the revoked
and new KSKs sign the key set.  Please see Figure 2 in the high-level
technical architecture document
To use the notation from that figure, we are in the period T+60
through T+80, i.e., from the 60th day to the 79th day of a calendar
quarter.  Also, please note that the ZSK will never sign the root key
set in the current design: only KSKs sign the root key set (in this
design, anyway).


More information about the Dnssec-deployment mailing list