I've re-skimmed :-) the archive and to answer Ed's question:
I cannot think of an environment where the DNSKEY approach will work
and the DS approach "WILL NOT" work.
I still think it is preferable for the child zone owners to deal with
keys only. On the other hand we have to remember that EPP is a
registrar-registry protocol. The protocol does not enforce the
registrant (the zone owner) to deal with DS-es. In fact I can imagine
the registrar's tools to deal with the dificulties of DNSKEY to DS
transformation (e.g. web-interface that does a query, presents a
number of keys, user clicks, presents creditcard details, and DS is
generated).
There are two reasons why I think it may be usefull for the registry
to have the DNSKEY:
- troubleshooting: by storing both the DS and the DNSKEY in the
whois database there is an out-of band mechanism to troubleshoot
broken set-ups.
- DS regeneration: That only seems useful in the case the hashing
algorithm is to change. And in the case where the hash algorithm
needs to change troubles me a bit. But if SHA1 turns out to be
vulnarable we will have to do an algorithm roll too there are
larger issues at hand. In other words this is not a strong
motivation.
Concluding: the only argument for having the DNSKEY at the parent is
to store it in the WHOIS together with the DS in order to allow for
out of band troubleshooting. Is that important enough to allow for
the DNSKEY to travel over EPP?
DNSKEY as an attribute of the DS element is a fine method to acomplish
this as there is even a more direct link between the DNSKEY and the DS
record.
-- Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
