Hello Robert,
Thanks for the feedback, my comments are inline.
Gr,
Rik
This is a small nit, but please consider changing the document to address it.
The motivation for this extension leans on improving the security of
transferring information between registrars. It should be recast as providing
better automation and reliability instead. > In practice (and I think in
specification), it hinges on passing a password from the registrar of record
to the gaining registrar through some unspecified means (though typically
through the registrant). That password is required to be placed in the create
by the >? > gaining registrar as specified in this document in order for that
create to succeed at the registry. While it would be impractical and
error-prone, the same channel that was used to hand this password around
_could_ be used to pass the keying material this > extension addresses.
My proposal is to change the last sentence of the introduction to emphasise the
automation and reliability.
old text:
In this document we define an EPP extension to support and automate this
transaction.
new text:
In this document we define an EPP extension to support automation and a
reliable transfer of DNSSEC key material.
Reading draft-koch-dnsop-operator-change (an informational reference
currently) helped greatly with understanding this document. That draft
expired in 2014. Please be sure it advances, and consider making it a
normative reference.
If it is not going to move forward, consider pulling some of the transfer
mechanic recommendations and the definitions of losing/gaining entities into
this draft, unless they've already made it into the RFC series somewhere else?
The draft is not going forward. The draft describes one possible solution for
changing the DNS operator of a domainname. There are several more options to do
this (even without the use of EPP). In that sense it is informative. This
document focusses on the EPP protocol syntax. So I’m not in favour of making it
a normative reference.
The security considerations document says a server SHOULD NOT perform any
transformation on data under server management when processing a
<keyrelay:create> command. Can this point to more detailed discussion
somewhere? Why is this not a MUST >NOT? (What are the conditions where
violating the SHOULD NOT is the right thing to do? What are the risks a
server takes if it performs such a transformation?)
The reason it is in the text is that key relay commands only use the secure,
authenticated channel for relaying a DNSSEC key. There is no need for the
server to do anything else then put the DNSSEC key material on the poll queue
of another client. One of the major problems (or one advantage depending on how
you see things) with EPP is that every registry, especially the ccTLDs have
their own policies, extensions and local regulations. So making it a MUST NOT
can prevent a server from complying with this document in cases where local
regulations are not compliant. This also is against the E in EPP; extensible.
Micro-nit : In section 2.1 where you say "The <expiry> element MUST contain
one of the following", consider saying "The <expiry> element MUST contain
exactly one of the following”.
Done in the working copy.
smime.p7s
Description: S/MIME cryptographic signature