<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.5) --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-must-not-sha1-10" number="9905" category="std" consensus="true" submissionType="IETF" updates="4034, 5155" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3">

  <front>
    <title abbrev="MUST

<!--[rfced] We have updated the short title that spans the header of
the PDF file to more closely match the document title. Please let
us know of any objection.

Original:
   MUST NOT DNSSEC with SHA-1">Deprecating SHA-1

Current:
   Deprecating SHA-1 in DNSSEC Signature Algorithms
-->

    <title abbrev="Deprecating SHA-1 in DNSSEC Signature Algorithms">Deprecating the use Use of SHA-1 in DNSSEC signature algorithms</title> Signature Algorithms</title>
    <seriesInfo name="RFC" value="9905"/>
    <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization>USC/ISI</organization>
      <address>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization>Google</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2025" month="September" day="10"/> month="October"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<abstract>

<?line 48?>
<t>This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1
algorithms for the creation of DNS Public Key (DNSKEY) and Resource
Record Signature (RRSIG) records.</t>
      <t>It updates RFC4034 RFCs 4034 and RFC5155 5155 as it deprecates the use of these algorithms.</t>
    </abstract>
  </front>
  <middle>

<?line 56?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>The security of the protection provided by the SHA-1 algorithm <xref target="RFC3174"/> has been slowly diminishing
over time as various forms of attacks have weakened its cryptographic
underpinning.  DNSSEC <xref target="RFC9364"/> originally (originally defined in <xref target="RFC3110"/> target="RFC3110"/>) made extensive use
of SHA-1, for example example, as a
cryptographic hash algorithm in RRSIG Resource Record Signature (RRSIG) and Delegation Signer (DS)
records.

<!--[rfced] FYI: The acronyms appear to be mismatched with the
expansions, so we switched them accordingly as shown below.

Original:
   Since then, multiple other algorithms with stronger cryptographic
   strength have become widely available for DS records and for
   Resource Record Signature (DNSKEY) and DNS Public Key (RRSIG)
   records [RFC4034].

Current:
   Since then, multiple other algorithms with stronger cryptographic
   strength have become widely available for DS records and for
   Resource Record Signature (RRSIG) and DNS Public Key (DNSKEY)
   records [RFC4034].
-->

Since then, multiple other algorithms with
stronger cryptographic strength have become widely available for DS records
and for RRSIG and DNS Public Key (DNSKEY) records <xref target="RFC4034"/>.

<!--[rfced] Should the names of the IANA registries be included here
for clarity?

Original:
   Operators are encouraged to consider switching to one of the
   recommended algorithms listed in the [DNSKEY-IANA] and [DS-IANA]
   tables, respectively.

Perhaps:
   Operators are encouraged to consider switching to one of the
   recommended algorithms listed in the "DNS Security Algorithm
   Numbers" [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA]
   registries, respectively.
-->

Operators are encouraged to consider switching to one of the recommended algorithms
listed in the <xref target="DNSKEY-IANA"/> and <xref target="DS-IANA"/> tables, respectively.
Further, support for validating SHA-1 based SHA-1-based signatures has been
removed from some systems. As a result, SHA-1 as part of a signature algorithm
is no longer fully interoperable
in the context of DNSSEC. As adequate alternatives exist, the use of SHA-1 is
no longer advisable.</t>
      <t>This document thus further deprecates the use of RSASHA1 and
RSASHA1-NSEC3-SHA1 for DNS Security Algorithms.</t>
      <section anchor="requirements-notation"><name>Requirements notation</name>

<t>The anchor="requirements-notation">
        <name>Requirements Notation</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="deprecating-sha-1-from-dnssec-signatures-and-delegation-rrs"><name>Deprecating anchor="deprecating-sha-1-from-dnssec-signatures-and-delegation-rrs">
      <name>Deprecating SHA-1 from DNSSEC Signatures and Delegation RRs</name>
      <t>The RSASHA1 <xref target="RFC4034"></xref> target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref target="RFC5155"></xref> target="RFC5155"/> algorithms MUST NOT <bcp14>MUST NOT</bcp14>
be used when creating DS records.  Operators of validating resolvers MUST <bcp14>MUST</bcp14> treat RSASHA1
and RSASHA1-NSEC3-SHA1 DS records as insecure.  If no other DS records of
accepted cryptographic algorithms are available, the DNS records below the
delegation point MUST <bcp14>MUST</bcp14> be treated as insecure.</t>
      <t>The RSASHA1 <xref target="RFC4034"></xref> target="RFC4034"/> and RSASHA1-NSEC3-SHA1 <xref target="RFC5155"></xref> target="RFC5155"/> algorithms MUST NOT <bcp14>MUST NOT</bcp14> be
used when creating DNSKEY and RRSIG records.  Validating resolver implementations
(<xref target="RFC9499"></xref> section 10) MUST target="RFC9499" sectionFormat="comma" section="10"/>) <bcp14>MUST</bcp14> continue to support validation using these
algorithms as they are diminishing in use but still actively in use for some
domains as of this publication. Operators of validating resolvers MUST <bcp14>MUST</bcp14> treat DNSSEC signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported, rendering responses insecure if they cannot be validated by other supported signing algorithms.</t>

</section> algorithms.</t></section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>

<!--[rfced] Is it correct that "DNSSEC Delegation" is uppercase and
"DNSSEC signing" is lowercase in this sentence? In the companion
document (draft-ietf-dnsop-rfc8624-bis-13 / RFC-to-be 9904), we
note that "DNSSEC signers" is used in the running text and that
"DNSSEC Delegation" is uppercase as it's only used in the name of
the columns and IANA registry.

Original:
   This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1
   for DNSSEC Delegation and DNSSEC signing since these algorithms are
   no longer considered to be secure.
-->

      <t>This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 for
DNSSEC Delegation and DNSSEC signing since these algorithms are no
longer considered to be secure.</t>
    </section>
    <section anchor="operational-considerations"><name>Operational anchor="operational-considerations">
      <name>Operational Considerations</name>

<t>Zone

<!--[rfced] May we refer to the "tables" as "IANA registries" for
clarity? Also, would "use" be clearer than "roll to"?

Original:
   Zone owners currently making use of SHA-1 based algorithms should
   immediately roll to algorithms with stronger cryptographic
   algorithms, such as the recommended algorithms in the [DNSKEY-IANA]
   and [DS-IANA] tables.

Perhaps:
   Zone owners currently making use of SHA-1-based algorithms should
   immediately use algorithms with stronger cryptographic algorithms,
   such as the recommended algorithms in the IANA registries
   [DNSKEY-IANA] [DS-IANA].
-->

      <t>Zone owners currently making use of SHA-1-based algorithms should
immediately roll to algorithms with stronger cryptographic algorithms,
such as the recommended algorithms in the <xref target="DNSKEY-IANA"></xref> target="DNSKEY-IANA"/> and <xref target="DS-IANA"></xref> target="DS-IANA"/> tables.</t>
      <t>Operators should take care when deploying software packages and
operating systems that may have already removed support for the SHA-1
algorithm.  In these situations situations, software may need to be manually built
and deployed by an operator to continue supporting the required levels
indicated by the "Use for DNSSEC Validation" and "Implement for DNSSEC
Validation" columns, which this document is not changing.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>[Note to IANA, to be removed by the RFC Editor:

<!--[rfced] Per IANA's protocol action note, should the registry fields
listed above will IANA section
be created by draft-ietf-dnsop-rfc8624-bis.]</t>

<t>IANA is requested updated as follows to capture all of IANA's updates to the
entries?

Current:
   IANA has set the "Use for DNSSEC Delegation" field column of the "Digest
   Algorithms" registry <xref target="DS-IANA"/> <xref target="I-D.ietf-dnsop-rfc8624-bis"/> [DS-IANA] [RFC9904] to MUST NOT for SHA-1 (1)
   and has added this document as a reference to MUST NOT.</t>

<t>IANA is requested to the entry.

   IANA has set the "Use for DNSSEC Signing" column of the
DNS "DNS Security
   Algorithm Numbers Numbers" registry <xref target="DNSKEY-IANA"/>
<xref target="I-D.ietf-dnsop-rfc8624-bis"/> [DNSKEY-IANA] [RFC9904] to MUST NOT for
   the RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) algorithms.</t>

<t>All algorithms and has added
   this document as a reference for these entries.

   All other columns should remain as currently specified.</t>

</section>

  </middle>

  <back>

    <references title='Normative References' anchor="sec-normative-references">

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify specified.

Perhaps:
   IANA has updated the requirements SHA-1 (1) entry in the specification. These words are often capitalized. This document defines these words "Digest Algorithms"
   registry [DS-IANA] [RFC9904] as they should be interpreted in IETF documents. This follows and has added this document specifies an Internet Best Current Practices
   as a reference for the Internet Community, and requests discussion and suggestions entry:

   Value: 1
   Description: SHA-1
   Use for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3110">
  <front>
    <title>RSA/SHA-1 SIGs DNSSEC Delegation: MUST NOT
   Use for DNSSEC Validation: RECOMMENDED
   Implement for DNSSEC Delegation: MUST NOT
   Implement for DNSSEC Validation: MUST

   IANA has updated the RSASHA1 (5) and RSA KEYs RSASHA1-NSEC3-SHA1 (7)
   algorithm entries in the Domain Name System (DNS)</title>
    <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
    <date month="May" year="2001"/>
    <abstract>
      <t>This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3110"/>
  <seriesInfo name="DOI" value="10.17487/RFC3110"/>
</reference>
<reference anchor="RFC3174">
  <front>
    <title>US Secure Hash "DNS Security Algorithm 1 (SHA1)</title>
    <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
    <author fullname="P. Jones" initials="P." surname="Jones"/>
    <date month="September" year="2001"/>
    <abstract>
      <t>The purpose of Numbers" registry
   [DNSKEY-IANA] [RFC9904] as follows and has added this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information as a
   reference for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3174"/>
  <seriesInfo name="DOI" value="10.17487/RFC3174"/>
</reference>
<reference anchor="RFC4034">
  <front>
    <title>Resource Records these entries:

   Number: 5
   Description: RSA/SHA-1
   Mnemonic: RSASHA1
   Zone Signing: Y
   Trans. Sec.: Y
   Use for DNSSEC Signing: MUST NOT
   Use for DNSSEC Validation: RECOMMENDED
   Implement for DNSSEC Signing: NOT RECOMMENDED
   Implement for DNSSEC Validation: MUST

   Number: 7
   Description: RSASHA1-NSEC3-SHA1
   Mnemonic: RSASHA1-NSEC3-SHA1
   Zone Signing: Y
   Trans. Sec.: Y
   Use for DNSSEC Signing: MUST NOT
   Use for DNSSEC Validation: RECOMMENDED
   Implement for DNSSEC Signing: NOT RECOMMENDED
   Implement for DNSSEC Validation: MUST
-->

      <t>IANA has set the DNS Security Extensions</title>
    <author fullname="R. Arends" initials="R." surname="Arends"/>
    <author fullname="R. Austein" initials="R." surname="Austein"/>
    <author fullname="M. Larson" initials="M." surname="Larson"/>
    <author fullname="D. Massey" initials="D." surname="Massey"/>
    <author fullname="S. Rose" initials="S." surname="Rose"/>
    <date month="March" year="2005"/>
    <abstract>
      <t>This document is part of a family "Use for DNSSEC Delegation" column of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication
"Digest Algorithms" registry <xref target="DS-IANA"/> <xref target="RFC9904"/>
      to <bcp14>MUST NOT</bcp14> for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, SHA-1 (1) and an example of each resource record is given.</t>
      <t>This has added this document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4034"/>
  <seriesInfo name="DOI" value="10.17487/RFC4034"/>
</reference>
<reference anchor="RFC5155">
  <front>
    <title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
    <author fullname="B. Laurie" initials="B." surname="Laurie"/>
    <author fullname="G. Sisson" initials="G." surname="Sisson"/>
    <author fullname="R. Arends" initials="R." surname="Arends"/>
    <author fullname="D. Blacka" initials="D." surname="Blacka"/>
    <date month="March" year="2008"/>
    <abstract>
      <t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) as a reference for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5155"/>
  <seriesInfo name="DOI" value="10.17487/RFC5155"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9499">
  <front>
    <title>DNS Terminology</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
    <date month="March" year="2024"/>
    <abstract>
      <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, entry.</t>
      <t>IANA has changed in the decades since set the DNS was first defined. This document gives current definitions "Use for many DNSSEC Signing" column of the terms used in the DNS in a single document.</t>
      <t>This document updates RFC 2308 by clarifying
"DNS Security Algorithm Numbers" registry <xref target="DNSKEY-IANA"/> <xref target="RFC9904"/> to <bcp14>MUST NOT</bcp14>
for the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed RSASHA1 (5) and new definitions can be found in Appendices A RSASHA1-NSEC3-SHA1 (7) algorithms and B.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="219"/>
  <seriesInfo name="RFC" value="9499"/>
  <seriesInfo name="DOI" value="10.17487/RFC9499"/>
</reference>
<reference anchor="RFC9364">
  <front>
    <title>DNS Security Extensions (DNSSEC)</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <date month="February" year="2023"/>
    <abstract>
      <t>This has added this document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for these entries.</t>
      <t>All other documents that want to refer to DNSSEC.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="237"/>
  <seriesInfo name="RFC" value="9364"/>
  <seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference> columns should remain as currently specified.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3110.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
      <reference anchor="DNSKEY-IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml"> target="https://www.iana.org/assignments/dns-sec-alg-numbers">
        <front>
          <title>Domain Name System Security (DNSSEC) Algorithm Numbers</title>
          <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <organization/>
          </author>
    <date year="n.d."/>
        </front>
      </reference>
      <reference anchor="DS-IANA" target="http://www.iana.org/assignments/ds-rr-types">
        <front>
    <title>Delegation
          <title>DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms</title>
          <author initials="" surname="IANA" fullname="IANA">
      <organization></organization>
            <organization/>
          </author>
    <date year="n.d."/>
        </front>
      </reference>

<!--
draft-ietf-dnsop-rfc8624-bis-13
companion doc RFC 9904
in AUTH48 as of 10/30/25
-->
      <reference anchor="I-D.ietf-dnsop-rfc8624-bis"> anchor="RFC9904" target="https://www.rfc-editor.org/info/rfc9904">
        <front>
          <title>DNSSEC Cryptographic Algorithm Recommendation Update Process</title>
          <author fullname="Wes Hardaker" initials="W." surname="Hardaker"> surname="Hardaker" fullname="Wes Hardaker">
            <organization>USC/ISI</organization>
          </author>
          <author fullname="Warren Kumari" initials="W." surname="Kumari"> surname="Kumari" fullname="Warren Kumari">
            <organization>Google</organization>
          </author>
          <date day="4" month="June" year="2025"/>
      <abstract>
	 <t>   The DNSSEC protocol makes use of various cryptographic algorithms to
   provide authentication of DNS data and proof of non-existence.  To
   ensure interoperability between DNS resolvers and DNS authoritative
   servers, it is necessary to specify both a set of algorithm
   implementation requirements and usage guidelines to ensure that there
   is at least one algorithm that all implementations support.  This
   document replaces and obsoletes RFC8624 and moves the canonical
   source of algorithm implementation requirements and usage guidance
   for DNSSEC from RFC8624 to an IANA registry.  This is done both to
   allow the list of requirements to be more easily updated, and to
   allow the list to be more easily referenced.  Future extensions to
   this registry can be made under new, incremental update RFCs.  This
   document also incorporates the revised IANA DNSSEC considerations
   from RFC9157.

   The document does not change the status (MUST, MAY, RECOMMENDED,
   etc.) of the algorithms listed in RFC8624; that is the work of future
   documents.

	 </t>
      </abstract> month='October' year='2025'/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc8624-bis-13"/> name="RFC" value="9904"/>
        <seriesInfo name="DOI" value="10.17487/RFC9904"/>
      </reference>
    </references>

<?line 140?>

    <section anchor="acknowledgments"><name>Acknowledgments</name> anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>The authors appreciate the comments and suggestions from the
      following IETF participants in helping produce this document: Mark Andrews,
Steve Crocker, Peter Dickson, Thomas Graf, Paul Hoffman, Russ Housley, Shumon
Huque, Barry Leiba, S Moonesamy, Yoav Nir, Florian Obser, Peter
Thomassen, Stefan Ubbink, Paul Wouters, Tim Wicinski, <contact
      fullname="Mark Andrews"/>, <contact fullname="Steve Crocker"/>, <contact
      fullname="Peter Dickson"/>, <contact fullname="Thomas Graf"/>, <contact
      fullname="Paul Hoffman"/>, <contact fullname="Russ Housley"/>, <contact
      fullname="Shumon Huque"/>, <contact fullname="Barry Leiba"/>, <contact
      fullname="S. Moonesamy"/>, <contact fullname="Yoav Nir"/>, <contact
      fullname="Florian Obser"/>, <contact fullname="Peter Thomassen"/>,
      <contact fullname="Stefan Ubbink"/>, <contact fullname="Paul Wouters"/>,
      <contact fullname="Tim Wicinski"/>, and the many members of the DNSOP working group
      Working Group that discussed this draft.</t> specification.</t>
    </section>
<section anchor="current-algorithm-usage-levels"><name>Current algorithm usage levels</name>

<t>The DNSSEC scanning project by Viktor Dukhovni

<!-- [rfced] Because this document updates RFCs 4034 and Wes Hardaker
highlights 5155, please
review the current deployment errata reported for each
(<https://www.rfc-editor.org/errata/rfc4034> and
<https://www.rfc-editor.org/errata/rfc5155>) and let us know if
you confirm our opinion that none of various algorithms on them are relevant to the
https://stats.dnssec-tools.org/ website.</t>

<t>&lt;RFC Editor: please delete this section upon publication&gt;</t>

</section>
<section anchor="github-version-of-this-document"><name>Github Version
content of this document</name>

<t>While document.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this document nature typically
result in more precise language, which is under development, it can be viewed, tracked,
fill here:</t>

<t>https://github.com/hardaker/draft-hardaker-dnsop-must-not-sha1</t>

<t>&lt;RFC Editor: please delete helpful for readers.

Note that our script did not flag any words in particular, but this section upon publication&gt;</t>

</section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA61YbW/bOBL+zl8xl35JANtN+rK7NQ6H9SZpE7RNelbaolcU
B0oaSzxTpMqh7BqB//thSMpWmnT39u4+haFocl6eeeYhx+Ox8MprnMLBGbYO
C+mVqcDXCB0h2AVkF7PxCSgDZ1dZdn4KpCojfecQpK6sU75u6EDIPHe4msLb
99kNXF3f9KvXytdxC1HawsgGp1A6ufBjhX4xLg3Zdtx05MfG+jHV8mR8ciwK
6bGybjMF8qVQrZuCdx35J8fHL46fCPIOZTOFy/Obl6JrS+mRpvDs+OmzETw/
ef5cCPLSlP+U2hqcwgZJtGoKn70tRkDWeYcLGgFtmjgobdHItlWm+iKE7Hxt
3VQAjAUAgDI0hY8TuJCulEt0YTI68hHp7rR11RTeZ6ePL7PLMIGNVHoK7Ouv
dVpJE4P+3vavu0Y6NdxcOodmOB92f2VtpXG4+Tos/HUZFoa9hbGukV6tkN2Y
vzx9cnLyIg2fnpwc74Y/P0tDjl0acgDT8Jf9ghfPXvQ7vHj6U5g9u8pen38a
X86uZtNgzz5yey/4a5jw0lXop3BQe9/S9PHj9Xo9UdLIiXXVY0kMqwaNp8el
oTFhMZa6GpuuydE9ODf5VvtGH8TNI4TPbCOVgSvZIGQb8thAhkXnlN/AYQTk
Ecx61MJV3Ihdyf4rN37XCxo7N/abFumujaixkl5ZA5mqDDo4PMuOYI5kO1cg
zLGwroTD+fwIbjYtwpmqkPzebBJCmcU+wUKMx2OQOXknCy/ETa2IEd2xHVCm
okYa1jQP59ksu5idgDRlPx5fZeenT8c8FPvihoV14ReFw2i4XXDy4V2Xa1XA
a4zRfX3+6SjulnwRyZdsxxiH83l2+eoIXPhAEyEuPaQC7mEYt4g4BEmgfscJ
GpLQJEaiUWWpUYhHcGm8s2VXsM0cFwTq0ZBi0DrrMXzn4UqVWEK+CZ8i7e12
h9vbVDHbLdSSIEc0QNqu9QZK1SijqFamEnaFDrxqkG1fSadsFyLYEB8qvZfF
kqCWK4Q1yiUaLEF5gsJtWm8rJ9taFaIzJbpWGaNMNYGeTIMNXH7bLVinKmWk
1pvetJPj7RYaWSLgN4+G1CqESvQcPgqJxG+yaXWwToo7h7Jb9cBjZSCkKyTk
YdiKPpEAmTIFcuTMCJpOe8WHWF+jG6QotAOmb2sqdHd9BmZ1U/k6BifHwjYI
a1Wi3oBcSaVlrjH4cJb1CALBxvHc9wU0AN0Qm9/j9i4gYygZhdvtBMR1i056
6wikQ0BT2M7JCkvwFgprSJXogNbKF3Vomhas2dUXb9k0aBhTgwgIrchzzk1Y
dXs7oNHtNth4e5v4aLsFz07TCBxSy0hdod5MxMvOcWRHQF3bWudDBFZSqzK2
7wjeXBKW+35NO9wKh41dYQkLZxsgjjMFuqQJzAgkn9ZpP+qLgKCVzgf8PtT+
QSgCY0HHrC46BqUyHp3lAOYaRfK2sMbjN58IJDs/jeeV+LWTnnf06EzgNQL8
psiPHlAiJPZnyXKliE+YfE98vua6i3H6AYEMGFDcZ8CItKts30JmQ6p59Ajm
+LVTDgPfg7FeRqIBAOaaJW5gHUB1wKLoYBT/sjji8fz87+8v5+dnPM4uZm/e
7AZxBW9zkF1cv3+TlvBo/+PT67dvz6/O4u9Zb3039Xb2Ke7BgDq4fndzeX01
e3MQYTeMEyPbW8gxZqx1yOiUBCVS4VSOpQgqBX47fQcnz2KFsJ7YbuP4l8iJ
61D5fJo1epP+9TVuQLYtSpd2kVpDIVvlpaYRH0O1XRuo0XEKH8FQhMZ8B4wm
Asz2WP6OlOZzihTfJ/VzKuQvP2hwYQH3mC/D6uwzJPKAkjL4kRqfqQbEMwHY
s4NdDIvPIVm9Qpd2Y63q/whrA0bjlmdCo8IJwOWCKyvy6GCRXQhZFNhyru6y
6MAZTu2OOGMlMZ77PXLUds2zotzHsbXK+Gh4jtH2CIedTf/PMEOO4qEwB0qM
O4YOtA/6h/txBsUNjcEcXCBx+DkJ1i/c8INbJ8dH8VBmIGW6gPmePPvcWQMd
pdsP4VABSUpQdjhs9gxo5pK880BeaQ0yUXT/hTmE+VWUQZqGnUJ/UARtaEPh
3MmfApMY3MR4zcDQ3xd1IEl0JrmNJXcV1hnpnNYawn2iQS2i04U0xnqGQ7IL
S5FvEiZ3mz1gzURwRe/o8zR1zJSl/0io/oE/C+v6YAy4IPX5YYioVyd3FGPI
p7EiNZO+pccGnye5GHkp5kdZI/U9R/4Ruv7acJaKji9jXm+gkUs++U7vih15
YADVttOlUE2DpZKekeOs1nz+d6oJfqCa9stGgrqiTlj9kfxIjfjzQHXE0v2c
NMeXJDkmYiB/opng5RKh4KCFei2x1XYTwmsXfs3zrSyWsor0LGyMGX+P6gJ8
LT00chMlntQOZbmBXo0MxcxOgu/LkNnQpByS8l0M//5s3tfgLnmNNF2Qx3mn
tA86MRocNb40YJN/Sc5FXkhG9I8gLvb4EjSuUJNQpuSa3d8TDt6nMk+I+7Aj
k4PYey97dhqsEsNVhdVdY2gE61oV9XftOSgrD0UtTcV3gXCvmV3N7oHw85X1
gdX46yjFoI9ssnX+8hTOS+Utv6cE5ypF3m1goVCX1EtTmVu+nTCf5enWF/e4
93DjFsUvPz15Ns4VTb4IEQxTFIKGYStmWfQPBmpfsAfx/CScxcG9G+/B3tKh
Nr69/cvl+GzysD3bLQg+LRbe4ckR29L3ncmftDWLNNLnqrf0YXXYvyvcMXoo
8sUfGT6wVPTF0DPh4fOjH7Hh4c9Hd9l3pnWi6YSxvpAdhocSOeQrvl+ohcIy
3aNzWSwZbbNiaexaY1kFoRvbf3wjIdZ2DgtmrqTvm6iG2ULqKs5jKNIg4njF
wmpt13xR5se7cK9QhWol/0ixDtT8DMe38bILjD0ohim8lW4JM1M6XNNIZB5X
CKfOFku+C71DzyJJFUuyZgQ3tW0kwSsnFyN4JzsNF3axaKQZwbwjggvbkcbN
CLK6a6wRF93XDkfwm3RuA29Q5XIEGby11iDJZjOCT1au4Eq5EbzU1ilp4Dqn
3cEinkcsezOPC2ngfZ4rs0yHf7SdR0cjuFENfFSFMrRUUTBzXBppNqLBCJx0
gzy7yq7f8R0iNJLK2a6NDFoqKjriVhLjw2UZm+1pTOfgbtaRrLBnr5C7vjVy
X0+x/hcWngv8g1oyH551y9qujArW3XnkrFVVa1XVPjaZhJ5ErIGwgnyJrx6D
tmMDcYv+7Y+89DQpDfGbnrdWU3g/gzXmpDx33L8OuarVKAmBZapPmOiFXdey
aN0rqb9xFF4pX3c5fEBH6bnqDo6E+FgrjfeZNry6QMmxsi1Pjvj1qZAmiB+F
a9ZM/My2xHIkFkyQfHGZip1jVTh5Utjmcf/c+ziyZv/vQ0/e/4u7/waxDAzO
whcAAA== should
still be reviewed as a best practice.
-->

  </back>
</rfc>