One document matched: draft-ietf-dnsext-dnssec-registry-fixes-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="yes"?>
<rfc ipr="pre5378Trust200902" category="std" docName="draft-ietf-dnsext-dnssec-registry-fixes-03" updates="4034">
<front>
<title abbrev="IANA-Registry-Fix">DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition</title>
<author fullname="Scott Rose" initials="S." surname="Rose">
<organization> NIST </organization>
<address>
<postal>
<street>100 Bureau Dr.</street>
<city>Gaithersburg</city>
<code>20899</code>
<region>MD</region>
<country>USA</country>
</postal>
<phone>+1-301-975-8439</phone>
<email> scottr.nist@gmail.com </email>
</address>
</author>
<date month="April" year="2010"/>
<area> Internet Area </area>
<workgroup> DNS Extensions Working Group </workgroup>
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
<abstract>
<t>
The DNS Security Extensions (DNSSEC) has an IANA registry to allocate
cryptographic algorithm suites for use in generating digital signatures over DNS data.
Newly introduced cryptographic algorithms to DNSSEC mean implementors need to
know which algorithms need to be implemented, which are optional, and which are obsolete.
This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC)
Algorithm Numbers to list their status for use.
</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MANDATORY", "DISCRETIONARY", "OBSOLETE",
"DISCOURAGED", "ENCOURAGED" and "RESERVED" in this
document are to be interpreted as described in <xref target="I-D.ogud-iana-protocol-maintenance-words" />
</t>
<t>The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119" />.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
The DNS Security Extensions (DNSSEC) <xref target="RFC4033" />, <xref target="RFC4034" />,
and <xref target="RFC4035" /> uses digital signatures over DNS data
to provide source authentication and integrity protection. DNSSEC uses an IANA registry
to allocate codes for digital signature algorithms (consisting of a cryptographic
algorithm and one-way hash function). Certain digital signature algorithms are
considered MANDATORY to implement for interoperability while others are listed as
OPTIONAL or OBSOLETE.
</t>
<t>
The original list of algorithm status is found in <xref target="RFC4034" />.
Other DNSSEC documents have added new algorithms or changed the status of
algorithms in the registry. However, implementors
must read through all the documents in order to discover which algorithms are mandatory to
implement and which are optional or no longer used.
</t>
<t>
This document requests a column to be added to the IANA registry for Domain Name
System Security (DNSSEC) Algorithm Numbers. This column will list the current status of each digital
signature algorithm in the registry.
</t>
</section>
<section title="DNS Security Algorithm Number Subregisitry Fixes">
<t>
The DNS Security Algorithm Number subregistry (part of the Domain Name
System (DNS) Security Number registry) will be modified to include a new column.
This column will contain the current implementation requirements of the given
algorithm. This document does not make any changes to any other column in the
registry table.
</t>
<t>
There are additional fixes to entries that are described in sub-section 2.1.
The overall new registry table is in sub-section 2.2. The values for the status
were obtained from <xref target="RFC4034" /> with updates for algorithms
specified after the original DNSSEC specification. The status of algorithms marked
OPTIONAL in <xref target="RFC4034" /> are changed to DISCRETIONARY as defined in
<xref target="I-D.ogud-iana-protocol-maintenance-words" />. The status of algorithms
marked NOT RECOMMENDED in <xref target="RFC4034" /> are changed to OBSOLETE as
defined in <xref target="I-D.ogud-iana-protocol-maintenance-words" />.
</t>
<section title="Individual Domain Name System Security (DNSSEC) Algorithm Number Registry Entry Fixes">
<t>
This document changes three entries in the Domain Name System Security (DNSSEC)
Algorithm Registry. They are:
</t>
<t>
The description for allocation number 4 is changed to "Reserved until 2020".
</t>
<t>
The description for allocation number 9 is changed to "Reserved until 2020".
</t>
<t>
The description for numbers 11, 13-251 are changed from Unassigned to the following:</t>
<t><list style="hanging">
<t hangText="*">Allocation number 11 is changed to "Reserved until 2020".</t>
<t hangText="*">Allocations 13-251 remains Unassigned.</t>
</list></t>
<t>
The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are both set to DISCRETIONARY.
The status of RSA/SHA-256 and RSA/SHA-512 are set to ENCOURAGED as it is believed
that these algorithms will replace older algorithms (e.g. RSA/SHA-1) that have a
perceived weakness in their hash algorithm (SHA-1).
</t>
</section>
<section title="Domain Name System Security (DNSSEC) Algorithm Number Registry">
<figure><preamble>
As of the current time, the DNS Security Algorithm Number subregistry would look
like the following:
</preamble>
<artwork>
Zone Trans
Number Description Mnem. Sign Sign Status Reference
------ ----------- ------ ---- ----- ------------ ---------
0 Reserved [RFC4398]
1 RSA/MD5 RSAMD5 N Y OBSOLETE [RFC4034],
[RFC3110]
2 Diffie-Hellman DH N Y DISCRETIONARY [RFC2539]
3 DSA/SHA-1 DSASHA1 Y Y DISCRETIONARY [RFC2536],
[RFC4034],
FIPS 186-3,
FIPS 180-3
4 Reserved until ECC
2020
5 RSA/SHA-1 RSASHA1 Y Y MANDATORY [RFC4034]
6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y DISCRETIONARY [RFC5155]
-SHA1
7 RSASHA1-NSEC3 RSASHA1- Y Y DISCRETIONARY [RFC5155]
-SHA1 NSEC3-
SHA1
8 RSA/SHA-256 RSASHA256 Y * ENCOURAGED [RFC5702]
9 Reserved until
2020
10 RSA/SHA-512 RSASHA512 Y * ENCOURAGED [RFC5702]
11 Reserved until
2020
12 GOST R GOST-ECC Y * DISCRETIONARY [RFCTBD]
34.10-2001
13-251 Unassigned
252 Reserved for INDIRECT N N DISCRETIONARY [RFC4034]
Indirect keys
253 private algo- PRIVATE Y Y DISCRETIONARY [RFC4034]
254 private algo- PRIVATEOID Y Y DISCRETIONARY [RFC4034]
255 Reserved
</artwork>
</figure>
<t>
The requirement status for all new algorithms will be DISCRETIONARY unless
a Standards Track document changes that (possibly including the
Standards Track document defining the algorithm). Only a Standards
Track document may make an algorithm ENCOURAGED or MANDATORY or remove
the MANDATORY or ENCOURAGED designation (to DISCOURAGED or OBSOLETE for
example).
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document consists entirely of DNS IANA Considerations and
includes the following changes detailed in Section 2.1:
</t>
<t>
The description of allocation 4 is changed from "Reserved for ECC" to
"Reserved until 2020".
</t>
<t>
The description of allocation 9 is changed from "Unassigned" to "Reserved
until 2020".
</t>
<t>
The description for numbers 11, 13-251 are changed from Unassigned to the following:</t>
<t><list style="hanging">
<t hangText="*">Allocation number 11 is changed to "Reserved until 2020".</t>
<t hangText="*">Allocations 13-251 remains Unassigned.</t>
</list></t>
<t>
The references for current algorithms in the table in Section 2.2 have been
updated to remove obsolete RFC's and replaced with the current reference.
</t>
<t>
The references to FIPS 180 and FIPS 186 have been updated (to FIPS 180-3 and
FIPS 186-3 respectively) to reflect the latest versions. These revisions
are maintenance updates and the main content of the FIPS documents have
not changed.
</t>
<t>
The new table is in Section 2.2. The Domain
Name System (DNS) Security Algorithm Number registry is
available at http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This document seeks to add a column to an existing IANA registry. It is not meant
to be a discussion on algorithm superiority. No new security considerations are
raised in this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4033" ?>
<?rfc include="reference.RFC.4034" ?>
<?rfc include="reference.RFC.4035" ?>
<?rfc include="reference.I-D.ogud-iana-protocol-maintenance-words" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2536" ?>
<?rfc include="reference.RFC.2539" ?>
<?rfc include="reference.RFC.3110" ?>
<?rfc include="reference.RFC.4398" ?>
<?rfc include="reference.RFC.5155" ?>
<?rfc include="reference.RFC.5702" ?>
<?rfc include="reference.FIPS.186-3.2009" ?>
<?rfc include="reference.FIPS.180-3.2008" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:16 |