One document matched: draft-ietf-dnsext-dnssec-registry-fixes-00.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-00" >
<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> scott.rose@nist.gov </email>
</address>
</author>
<date month="October" year="2009"/>
<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 implmented, 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 "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">RFC 2119</xref>.
</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 algorithm (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>
Other DNSSEC documents have added new algorithms or changed the status of
algorithms in the registry. However, without reading all the documents, implementors
must read through all the documents to discover which algorithms are MANDATORY to
implement and which are OPTIONAL or obsolete.
</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 status of the given algorithm.
This status . 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.
</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 8 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 allocation number 11 is changed to "Reserved until 2020".
</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],
[RFC2537]
2 Diffie-Hellman DH N Y OPTOINAL [RFC2539]
3 DSA/SHA-1 DSASHA1 Y Y OPTIONAL [RFC3755],
[RFC2536],
FIPS 186,
FIPS 180-1
4 Reserved until ECC
2020
5 RSA/SHA-1 RSASHA1 Y Y MANDATORY [RFC3755],
[RFC3110]
6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y OPTIONAL [RFC5155]
-SHA1
7 RSASHA1-NSEC3 RSASHA1- Y Y OPTIONAL [RFC5155]
-SHA1 NSEC3-
SHA1
8 RSA/SHA-256 RSASHA256 Y * OPTIONAL RFC-ietf-
dnsext-dnssec-
rsasha256-14
9 Reserved until
2020
10 RSA/SHA-512 RSASHA512 Y * OPTIONAL RFC-ietf-
dnsext-dnssec-
rsasha256-14
11 Reserved until
2020
12-251 Unassigned
252 Reserved for INDIRECT N N OPTIONAL [RFC4034]
Indirect keys
253 private algo- PRIVATE Y Y OPTIONAL [RFC3755],
domain name [RFC2535]
254 private algo- PRIVATEOID Y Y OPTIONAL [RFC3755],
OID [RFC2535]
255 Reserved
</artwork>
</figure>
<t>
Newly allocated algorithms will need to state their intended status in
their specification. Any changes to a previously allocated algorithm's
status MUST be done by a standards track document.
</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 8 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 of allocation 11 is changed from "Unassigned" to "Reserved
until 2020".
</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" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2535" ?>
<?rfc include="reference.RFC.2536" ?>
<?rfc include="reference.RFC.2537" ?>
<?rfc include="reference.RFC.2539" ?>
<?rfc include="reference.RFC.3110" ?>
<?rfc include="reference.RFC.3755" ?>
<?rfc include="reference.RFC.4398" ?>
<?rfc include="reference.RFC.5155" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:23:10 |