Re: Example of stupid inconsistencies between registries

Mark Elkins <[email protected]>
Newsgroups gmane.ietf.provreg
Organization Posix Systems
Message-ID <[email protected]>
On Thu, 2012-03-08 at 07:02 +0100, Patrik Fältström wrote:

> A registry that want to be "thick" can still receive the DS, then fetch
> the DNSKEY from DNS which they validate against the DS. If they want
> create a new DS they can do so with whatever digest algorithm they want
> and not even publish the DS that the client passes to them.
> 
> So the DS should be enough. Everything else is bonus. Or am I
> completely confused before enough coffee here in the morning?

I'd agree with you. A DS record over EPP (I'd thus assume a SSL/TLS type
of secured link) gives the Registry enough validatable information to
fetch DNSKEY records via unsigned DNS and then validate them.

Personally - just sending a trigger to the Registry to come fetch my
DNSKEY from me would statistically be enough.  The Registry has my
Nameservers - they can ask each NS in turn for my DNSKEY - if all
Nameservers agree - its most probably correct... OK - so I'll send a
valid DS record as a trigger.

Once signed, a simple trigger should be enough though? The Registry can
ask via DNSSEC for any new DNSKEY records as then the DNS transaction is
signed (as in the AD bit is set)... OK - It'll still be a DS Record
trigger.

This is probably of insignificance to anyone running a properly
configured Registry<-->Registrar systems but for anyone doing EPP type
updates via a web portal, the less one has to type - the better. 
-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       [email protected]  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
smime.p7s (application/x-pkcs7-signature, 3.9 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.