Hi Tony, The intention was that those distributing code that relies upon retrieval of an authentic trust anchor would make arrangements with ICANN to sign trusted copies of the relevant objects themselves and have those signatures published alongside the ICANN-generated signatures.
So, ISC could use the same PGP key as they use to sign BIND9 distributions, Apple could use a key derived from their code-signing CA, etc. In this way users could have the same trust in the retrieved trust anchor as they do in the software that has retrieved it. We have not had significant interest from vendors in developing this approach, but we remain interested. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-04-06, at 17:22, Tony Finch <[email protected]> wrote: > On 6 Apr 2013, at 10:04, Joe Abley <[email protected]> wrote: >> On 2013-04-06, at 16:55, Tony Finch <[email protected]> wrote: >>> >>> Validator vendors have to provide an out-of-band trust anchor update >>> mechanism to cope with this. It needs to be coded and included in long-term >>> support releases of validators and operating systems before rollover, I >>> think. >> >> draft-jabley-dnsop-validator-bootstrap. > > Still needs implementation. > > My point about trustworthiness is that there is (as far as I know) no > documentation of how the private keys are managed for the certificates / > signatures on the trust anchor files, which rather undermines the elaborate > root KSK management. I am also worried about being vulnerable to a screwup by > any number of CAs; it would be good to pin the list of CA certs that might be > used to verify the DNS trust anchor signatures. > > Tony. > -- > f.anthony.n.finch <[email protected]> http://dotat.at/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
