Re: DNSSEC operator change [Re: Example of stupid inconsistencies between registries]
"Michael Young" <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
I did read it, I was basically agreeing with the process that document lays out, except I don't like the registry being the dropbox for the zsk exchange from old to new operator. Clearing I wasn't expressing that well enough! However I suppose since I have an opinion, I should suggest another alternative then, let me think on that and I'm happy to comment on your next version. -M -----Original Message----- From: Peter Koch [mailto:[email protected]] On Behalf Of Peter Koch Sent: March-08-12 1:50 PM To: Michael Young Cc: [email protected] Subject: DNSSEC operator change [Re: [provreg] Example of stupid inconsistencies between registries] Michael, > I'm not sure why as a DNS operator I would want to either send a ZSK > (signed by my KSK) or receive a ZSK signed by a KSK I don't control > through the domain registry. may i humbly ask whether you have read the draft Antoin pointed to? > I tend to think this should stay between the two DNS operators, as the > keys Absolutely, but in the process of the operator change, these two entities for which we cannot safely assume an authenticated, secure channel to exist, need to exchange ZSK information. Old data can be gathered DNSSEC secured from the DNS but there is no generic way for the losing operator to access the gaining operator's ZSK. That's where the registry comes in providing a dropbox that both operators (at least through their registrars) have access to. In that sense, the ZSk is not registered and is not processed by the registry other than being relayed. I'd hope that the draft is clear about this and the difficulties arose from the fact it was dropped inmidst this discussion about which object to register. If the draft is not explaining that background well, that's a pity, and we'd appreciate feedback. That said, a -04 version is in preparation and while there is a provisioning (read: EPP) component to it that would go into a separate document, we are most likely going to ask for feedback on the DNSOP WG mailing list to address the key timing issues first. Other comments are of course welcome, just trying to avoid the spread. Best regards, Peter _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg