Re: New Version Notification for draft-gieben-epp-keyrelay-00.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 25-01-13 13:40, Patrik F￤ltstr￶m schreef:
> On 24 jan 2013, at 09:21, Antoin Verschuren
> <[email protected]> wrote:
> 
>> Abstract: This document describes an Extensible Provisioning
>> Protocol (EPP) extension mapping for the purpose of relaying
>> DNSSEC key material from a one registrar to another.  The mapping
>> introduces <keyrelay> as a new command in EPP.
> 
> I think the draft in a quite complicated way mixes up transfer of
> domains between registrars and change of DNS operator. Those are
> two very different operations, and they should not be mixed up.

You just stole my line Patrik :-).
As advocate of clearly separating registrar and DNS operator roles, I
can assure you that both the transfer and this EPP draft do so, and
I'm here to guard that separation.
But I can understand your worries.
perhaps we were not clear in explaining how a DNS operator change
would use this communication channel when no registrar change would
take place. I'm thinking of something along this line:
"A registrar may also use this keyrelay command to relay a key to his
own message queue. This is to accommodate a fully automated DNS
operator change when only 3th party DNS operators change, but the
registrar stays the same."
If you have better text, please let me know.

> Further, I do not understand the real need for a transfer of the
> key from the loosing to the gaining DNS operator, as I am a person
> that rather believe in an overlap in DS in the registry. I.e. DS
> created by the loosing DNS operator is published in parent zone
> until the zone is stable under DS from the gaining DNS operator.

Hmm, perhaps you should read
draft-koch-dnsop-dnssec-operator-change-04 first.

First of all, the issue we try to solve here is that a key needs to
travel from gaining to losing DNS operator over a secured channel. We
use the administrative channel for that as no other direct channel
exists:

[DNS operator]-[Registrant]-[Reseller]-[Registrar]-[Registry]-
[Registrar]-[Reseller]-[Registrant]-[DNS operator]

In this draft, we describe the EPP message that will only be used in
part of this channel: [Registrar]-[Registry]-[Registrar]

How secure communication takes place between the other players
involved is out of scope as they usually don't use EPP for that
communication. See also the security section of the draft.

A key also needs to travel from loosing (current) to gaining DNS
operator, but we can use DNS and validation for that when the current
zone is DNSSEC signed.

This step of relaying the keys between gaining and losing operator is
only the first step in a process where at the 3th step double DSes
exist at the parent. But in order for either one of those DSes to
validate child data during the NS change Both ZSK's need to be present
in both zones at both operators.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email protected]
XMPP: [email protected]
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRAozVAAoJEDqHrM883AgnOykIAJabjD9k6vHKpmOy2FnAy04E
t6L+O/XxrXmzbDCX3ca0XV/4UvYL0Par0tzdLe16ynNq4CHNJ7SEbE5FRuPv1+pM
QP4/b95SRKyRfcBYyGEn1ey7yGqv+eQTz0xetZWAAHKM2M949PrWt1kYjt6EfcS9
rhN2plmETZ+gkLxt4ZkDWLFYdEh9yAsZpoDZ6nll8vTSmGvolZ3o2mLE1Sr+bPWX
T0kbl9w4SWmY/GbWOIK54lhDwlyWyFt4HnYPaxFz7n8EJHPeKh0nLZlCgoZ6jG7H
WihMPmmlvvGw9BAE+eqFCv1xUzCYtWyZwIQDzrUR6H5LLUClXngPX/G1nqQrCws=
=88Ut
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg