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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.