On Thu, Mar 22, 2018 at 1:42 PM, Tony Finch <d...@dotat.at> wrote: > Shumon Huque <shu...@gmail.com> wrote: > > On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch <d...@dotat.at> wrote: > > > > > > From the provider point of view, I think there are a couple of models: > > > > > > (a) provider has KSK and ZSK; zone owner needs to be able to import > other > > > provider public keys into this provider's DNSKEY RRset, and export > signed > > > DNSKEY RRset. > > > > > > (b) provider only has ZSK; zone owner needs to be able to export public > > > keys, and import signed DNSKEY RRsets. > > > > One thing I would like to discuss is whether this document should > recommend > > just one model to maximise the chances that multiple providers implement > a > > common interoperable scheme that a zone owner can successfully deploy. > > Providers might be persuadable to implement both models, but anything > more > > than two, I would guess, will not be practical. > > I think providers need to implement all the functionality I sketched > above. The zone owner might act as provider (a) holding the KSK private > key; or they might outsource it. >
That would be great, but I think we need to get feedback from the providers that they are willing to implement both models, and if not, persuade them to do so, if that's the recommendation in the document. > > The risk the Olafur mentioned of a KSK provider dropping imported DNSKEYs > from other providers is probably a matter for contracts and lawyers :-) > Yes, that was my answer to Olafur in person (I'm sitting next to him right now in DOH :-) > But it sort of illustrates the point that this functionality is really > useful for phased migration from one provider to another without going > insecure. > Yes, indeed. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
