All,
I think this errata is incorrect: For an algorithm rollover it is
intended that at the "DNSKEY removal" step, the DNSKEYs are removed from
the zone, but the signatures stay. This is to play nicely with
conservative validators:
The conservative approach interprets this section very strictly,
meaning that it expects that every RRset has a valid signature for
every algorithm signaled by the zone apex DNSKEY RRset, including
RRsets in caches.
However, looking into this errata I do think there is an error in Figure
8 in section 4.1.4:
The figure should have the signature of the old KSK, called
RRSIG_K_1(DNSKEY) in the "DNSKEY removal" step.
Because a conservative validator may have the DNSKEY RRset cached that
includes DNSKEY_K_1, DNSKEY_K_2, DNSKEY_Z_1, and DNSKEY_Z_2.
Regarding the notes on this errata:
> because: I just don't think you can sign a zone without the
> corresponding ZSK's.
It is certainly possible to sign zones and not publish the corresponding
DNSKEY.
Best regards,
Matthijs
On 03-03-18 15:03, RFC Errata System wrote:
The following errata report has been submitted for RFC6781,
"DNSSEC Operational Practices, Version 2".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5273
--------------------------------------
Type: Technical
Reported by: Peter J. Philipp <rfcedi...@centroid.eu>
Section: 4.1.4
Original Text
-------------
Figure 8 on page 30.
Corrected Text
--------------
The figure should have the second ZSK DNSKEY, called DNSKEY_Z_10 under
DNSKEY removal because SOA_3 is doubly signed.
or
The figure should not have the second RRSIG for SOA_3 that is derived
from DNSKEY_Z_10.
because: I just don't think you can sign a zone without the
corresponding ZSK's.
Notes
-----
It looks wrong to me. A small technicality. I'll let the authors decide if
it's really wrong.
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--------------------------------------
Title : DNSSEC Operational Practices, Version 2
Publication Date : December 2012
Author(s) : O. Kolkman, W. Mekking, R. Gieben
Category : INFORMATIONAL
Source : Domain Name System Operations
Area : Operations and Management
Stream : IETF
Verifying Party : IESG
_______________________________________________
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
