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

Or alternatively, the vendors get together as a consortium and set up some
infrastructure whereby they manage this in a practical manner.

This is an important problem that is not limited to DNS trust roots.

But the people who would be interested in a solution are going to be the
type of people who consider real world business issues of the type that
cause many people on this list to stick their fingers in their ears and
chant 'la-la-la not listening'.

So it is really not a problem that I think is useful to address as part of a
DNSSEC infrastructure consideration.

On Thu, Jan 27, 2011 at 3:37 PM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

> On Thu, Jan 27, 2011 at 4:24 PM, Paul Wouters <paul@xelerance.com> 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
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>

-- 
Website: http://hallambaker.com/