Hi Paul, On 31 Oct 2018, at 14:54, Paul Vixie <p...@redbarn.org> wrote:
> Jim Reid wrote: > >>> On 31 Oct 2018, at 00:27, Mark Andrews<ma...@isc.org> wrote: >>> >>> Bootstrap is still a issue. Over fast TA rolling makes it more of >>> a issue. >> >> Indeed. And that's the underlying problem that needs to be fixed IMO >> - for instance when/if there's an emergency rollover. > > bootstrappers should have https access to a complete history of root ksk, > each one signed by its predecessor. this doesn't handle revocation, but > nothing in dnssec handles revocation, and that's by design, and so i'm > inclined not to worry about it. The existing scheme provides bootstrappers with a complete history of trust anchors (published by digest). The published object was intended to be accompanied by a detached signature that could be trusted by a vendor, since there was to be a certificate chain from the object-signing certificate back to an X.509 trust anchor that made sense to the client (e.g. an iOS code-signing key, a Windows code-signing key, an ISC code-signing key, etc, etc). This is described in RFC 7958. The only "vendor" that ever published such a certificate was the (largely proof-of-concept) "ICANN" vendor. I'm not suggesting that the scheme described in that document is good, or that it shouldn't be replaced with something better, but it's one possible starting point for the discussion. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
