This was the primary reason that the current proposal includes the option to do one or the other. It adds some complexity. Is the benefit worth it or not?
That's a question I wanted to raise.
If the DNSKEY is the basis of the transaction, then the registry can "do more" - it can display the keys in whois, it can generate the hash under "controlled" circumstances.
OTOH - is that the job of the registry? Why put the keys in whois when the "important" protocol is DNS? Why would the registry ever need to recalculate the hash? (A recalculation would only be *required* if the digest type - only SHA-1 is currently defined - were to be rescinded from code bases.)
The first issue to hash out is - whether a registry needs the key or even if the registry should get the key. Remember that "key at parent" was ditched in favor of the delegation signer record.
The second issue is whether the protocol ought to even support a choice. In my opinion, the DS option is required. If the protocol does not allow the DNSKEY option, we are cutting out a design choice. But is that a bad thing?
Is there a hard requirement that the epp-secdns retain the DNSKEY option? (I don't consider "maintaining the choice" or "pushing the decision up a level" as hard requirements.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
I would have been at the meeting, but I was busy raking the leaves from the (now) empty non-terminals in my yard. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
