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

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

Op 24-01-13 14:13, Klaus Malorny schreef:
>> 
>>> 3. How long shall the current registrar/name server operator
>>> add the DNSKEYs to the respective zone?
>> 
>> This question is process, not syntax.
> 
> I cannot agree. There are certain expectations with the protocol,
> namely that the current registrar performs the necessary steps to
> have the DNSKEYs published on the domain's name servers, and this
> is already "process".

Ah, I see how you look at it.
If that's the case, then we should make DNSSEC mandatory, which it
isn't. (though I would like it :-))

Secure transfers are not mandatory as well.
The only thing koch-dnsop-dnssec-operator-change describes is "if you
want to do a secure transfer, this is how you can do it".
We don't say you MUST do secure transfers because there is allways an
alternative to go insecure and we cannot mandate DNSSEC.

So if a key is relayed to a registrar, it is expected that he relays
the key to the DNS operator that is appointed by the registant. The
DNS operator can then publish the key to satisfy his customer, but we
have no contractual control over the DNS operator nor any RFC to make
that compulsory.

I guess we could have an expiration timer on the key, but who should
set that timer then ? Let's say a regular secure transfer can be done
in 3 days, what is a reasonable timer? 1 week ? And should the gaining
registrar set that timer ? And what if a gaining registrar sets the
timer to 1 year? Should the registry prohibit that by local policy ?
So suppose a registry does set a local policy of max 2 weeks for the
timer.
Then the timer can also be set by the losing registrar based on the
local policy of the registry, and we don't have to communicate that
timer over the protocol. It can be set in the cooperating DNS
operator's provisioning system, or even be deleted by hand at will.

The only thing a keyrelay command does is relay a key to facilitate a
secure transfer process for those that want on both sides, but that is
not mandatory to implement for every registrar or DNS operator.

- -- 
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)

iQEcBAEBAgAGBQJRAWTmAAoJEDqHrM883Agn68wH/1hKS2KI1nVYQLpZaeiYWHO1
ZOPZQ4Ya80fNtTsGiXaXniLeuFXJ4y51wbj4Zn5y4e7vW3ArogbblzRTEtlV05/6
00v5rZN+6QjGPjIj3Rr50EHmFAA86MravJRmOxQ90n937fYC5yXL2VNSoSxkHy3H
vRWY9pvNPDaH8v3Jx2f1id/ConKvfRlvTvmH6NMZkWFPKG7f6oVBOWyWXgUhii72
hP7KL5vRnr2JWWyCjGN4Dd+C12S42X40lquhqiJG626BZw55LP41r/IAMzdIzlft
i5N7cry2TRhz9BA9KdcpdVdtQPnwNs7ouahIKfiDSuHnySuWra85PTmg4Bi3uvI=
=6POX
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg