%% You should probably cite draft-ietf-dnsop-rfc5011-security-considerations-13 instead of this revision. @techreport{ietf-dnsop-rfc5011-security-considerations-12, number = {draft-ietf-dnsop-rfc5011-security-considerations-12}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/12/}, author = {Wes Hardaker and Warren "Ace" Kumari}, title = {{Security Considerations for RFC5011 Publishers}}, pagetotal = 20, year = 2018, month = mar, day = 23, abstract = {This document extends the RFC5011 rollover strategy with timing advice that must be followed by the publisher in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. This document contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document.}, }