%% You should probably cite draft-ietf-dnsop-rfc5011-security-considerations-13 instead of this revision. @techreport{ietf-dnsop-rfc5011-security-considerations-08, number = {draft-ietf-dnsop-rfc5011-security-considerations-08}, 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/08/}, author = {Wes Hardaker and Warren "Ace" Kumari}, title = {{Security Considerations for RFC5011 Publishers}}, pagetotal = 18, year = 2017, month = nov, day = 29, abstract = {This document extends the RFC5011 rollover strategy with timing advice that must be followed 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. It 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. 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.}, }