Re: [dnsext] Historical root keys: The Large Router Vendor Speaks

[Paul Hoffman <[e-mail]>]

Is there a reason that we are only focusing on one of the multiple 
proposals that this person proposed? Path II was:

  II. Provide our own key update service. This might be DNS-based or
      HTTP-based. It would provide either:

      a. The entire historical chain of DNS root KSKs, with older keys
	signing newer ones, so that the device could pick up from
	whatever key it had, OR

      b. Just the current root key, signed with a key validated by
	Cisco's private X.509 PKI (the same PKI we use to sign
         software), OR

      c. The chain of (a) further signed with a key from (b).

      We are obviously capable of this. We also obviously think it's
      inferior to (I).

It is not clear that it is inferior to (I) if doing (I) makes the entire 
system more fragile by adding another moving part.

I think (II)(b) looks quite sane, easy to do right now, and if this 
community ever agrees to a safe way to do (I) *and* implements it, doing 
a firmware update to switch over to it would not be hard. I would not 
hold my breath, though.

We're talking pre-loaded trust anchors here. They have the same power as 
pre-loaded software. If (II)(b) works for your software, it should work 
just fine for your trust anchors.