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

[Joe Abley <[e-mail]>]

Hi John,

On 2011-01-27, at 15:21, John Bashinski wrote:

> At the moment, the following are under consideration:
> 
>  I. Get IANA and the root zone to provide some kind of service for
>     getting up to date starting from old trust roots. This is our
>     preferred answer, because--
> 
>     a. Every vendor could use it..
> 
>     b. Every professional network admin would eventually be familiar with it
> 
>     c. Every firewall would probably eventually let it through.
> 
>     d. It would get a lot of scrutiny, and that would make it more
> 	trustworthy.
> 
>     e. We wouldn't have to commit to running a well-known service
> 	for ages and ages. To be honest, it's not that easy to get
> 	a big corporation to buy into something like that in a way
> 	that makes you feel as confident as I'd like to be in this.
> 
>     f. It could outlast any vendor.
> 
>     I do not have the authority to even *suggest* committing any
>     Cisco funds to supporting this, but I could ask. Perhaps others
>     on this list could think about asking their employers as well.
>     It's always easier to get money if the boss feels the need to
>     keep up with the Joneses...

Right now we publish trust anchors for the root zone as:

1. an XML file, which is signed separately using S/MIME and PGP. This file contains the current public key and also includes details of all previous public keys, annotated XMLishly to indicate over what periods of time they were intended to be used.

2. an X.509 certificate. One of the products of a key ceremony is an X.509 CSR, which we sign using an ICANN-maanged CA to produce the certificate.

It was our ambition with (2) to publish multiple certificates for each anchor, each one representing the same CSR signed by a different certificate authority. This would allow a software vendor who already runs a CA (e.g. for the purpose of signing software updates) to bootstrap trust in a published KSK public key using their own key, but it might also be useful with well-known and -used commercial CAs, too.

A client might then have a bootstrapping mechanism of

  - retrieve <http://data.iana.org/root-anchors/root-anchors.xml>;
  - retrieve the set of CRTs associated with the current KSK (as identified in the XML file, currently just <http://data.iana.org/root-anchors/Kjqmt7v.crt>, but potentially <http://data.iana.org/root-anchors/Kjqmt7v.crt.cisco>);

(both the above accomplished without using DNSSEC validation, or SSL, although those URLs are provided with HTTPS too)

  - use a local X.509 trust anchor (e.g. for a vendor CA, or the regular browser list of SysTrust-accredited commercial CAs, or something else) to verify that the trust anchor retrieved is correct and proper.

Don't interpret any of that as reluctance to discuss doing anything new at IANA to make this easier; I just want to make sure the existing mechanisms can't be made to work in a sensible way first.


Joe