Re: [dnsext] historal root keys for upgrade path?

[Brian Dickson <[e-mail]>]

On Thu, Jan 27, 2011 at 4:24 PM, Paul Wouters <[e-mail]> wrote:
> On Thu, 27 Jan 2011, Brian Dickson wrote:
>
>> Open question, to whoever feels like answering it:
>> Would the following, as a general mechanism for publishing someone
>> else's DNSKEY (securely) work?
>> (Here, "foreign" means, we don't hold the private keys)
>>
>> (1) Using a current, known-good trust anchor, retrieve and validate
>> the (foreign) DNSKEY data (possibly plural).
>> (2) For every algorithm in the set of foreign DNSKEY data :
>> (2a) Generate (one time only!!!)  a new public/private key pair for
>> our own (local) DNSKEY
>> (2b) Combine the local and foreign DNSKEY data into the apex of our
>> own zone file, for which we are authoritative.
>> (2c) Sign the DNSKEYs with our private keys
>
> Now you have just moved the problem. I need this DNSKEY as trust anchor. How
> do I know this will not be rolled and how to I get historic data on this
> key.

Sorry, I thought that was obvious... This DNS zone (or these zones)
would need to be maintained, actively, by $vendor.

The vendor is then responsible for the key not rolling, and the
accuracy of the served trust anchor data (root keys) in the zone, the
serving (or outsourcing the serving) of the zone, etc.

The only traffic to this zone will be bootstrapping devices, and
ideally just once per device.

The zones can be fed by a private master, and served literally from
anywhere the vendor wants.

The liability issues are strictly with the vendor to the itself (and
its customers), i.e. negligible.

It scales reasonably well, and the overhead, in terms of operational
management, while important to get right, is really insignificant.

Brian