Hi, I read this again. I still wonder if in the case of DNSSEC Delete Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is 0, the Digest/Public Key MUST be ignored.
This way, you don't have to change the CDS/CDNSKEY format defined in RFC 7344, most likely causing less problems with deployed software. Best regards, Matthijs _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop On 31-10-16 16:35, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Managing DS records from parent via CDS/CDNSKEY > Authors : Olafur Gudmundsson > Paul Wouters > Filename : draft-ietf-dnsop-maintain-ds-04.txt > Pages : 10 > Date : 2016-10-31 > > Abstract: > RFC7344 specifies how DNS trust can be maintained across key > rollovers in-band between parent and child. This document elevates > RFC7344 from informational to standards track and adds a standard > track method for initial trust setup and removal of secure entry > point. > > Changing a domain's DNSSEC status can be a complicated matter > involving multiple unrelated parties. Some of these parties, such as > the DNS operator, might not even be known by all the organizations > involved. The inability to disable DNSSEC via in-band signaling is > seen as a problem or liability that prevents some DNSSEC adoption at > large scale. This document adds a method for in-band signaling of > these DNSSEC status changes. > > This document describes reasonable policies to ease deployment of the > initial acceptance of new secure entry points (DS records) > > It is preferable that operators collaborate on the transfer or move > of a domain. The best method is to perform a Key Signing Key ("KSK") > plus Zone Signing Key ("ZSK") rollover. If that is not possible, the > method using an unsigned intermediate state described in this > document can be used to move the domain between two parties. This > leaves the domain temporarily unsigned and vulnerable to DNS > spoofing, but that is preferred over the alternative of validation > failures due to a mismatched DS and DNSKEY record. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
