From 020b3b1379697d227dcf9ab4185b90b360686272 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 12 Aug 2010 02:30:25 +0000 Subject: [PATCH] new draft --- ...t-ietf-dnsext-dnssec-registry-fixes-05.txt | 504 ------------------ ...t-ietf-dnsext-dnssec-registry-fixes-06.txt | 448 ++++++++++++++++ 2 files changed, 448 insertions(+), 504 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt deleted file mode 100644 index 8f63c1f269..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Updates: 2536, 2539, 3110, 4034, June 18, 2010 -4398, 5155, 5702 -(if approved) -Intended status: Standards Track -Expires: December 20, 2010 - - - DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition - draft-ietf-dnsext-dnssec-registry-fixes-05 - -Abstract - - 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 which lists their current - status for use. - -Status of This Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 20, 2010. - -Copyright Notice - - - - -Rose Expires December 20, 2010 [Page 1] - -Internet-Draft IANA Registry Fixes June 2010 - - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Terms Used in this Document to Indicate Status . . . . . . 3 - 1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 4 - - 2. DNS Security Algorithm Number Subregistry Fixes . . . . . . . . 4 - 2.1. Individual Fixes . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Updated Registry Snapshot . . . . . . . . . . . . . . . . . 5 - 2.3. Specifying New Algorithms and Updating Status of - Existing Entries . . . . . . . . . . . . . . . . . . . . . 6 - - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - - 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 - - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - -Rose Expires December 20, 2010 [Page 2] - -Internet-Draft IANA Registry Fixes June 2010 - - -1. Introduction - - The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033], - [RFC4034], and [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). - - The original list of algorithm status is found in [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. - - 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 at the time of writing and assigns status for algorithms - used with DNSSEC that did not have a status when they were originally - specified. This document updates the following: [RFC2536], - [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and - [RFCTBD]. - -1.1. Terms Used in this Document to Indicate Status - - The following terms are used within this document to indicate the - current implementation status of the given digital signature - algorithm as of the time of writing. Here, "implementation" refers - to any component (e.g. validator, signer, etc.) that conforms to this - document. Some of these terms were used without definition in - previous documents and are defined here. - - MANDATORY: Implementations MUST support this algorithm to be - considered currently inter-operable. - - OPTIONAL: Implementation MAY support this algorithm. The presence - or lack thereof this algorithm MUST NOT be used to judge - conformance to this document. - - ENCOURAGED: Implementations SHOULD support this algorithm, but - like DISCRETIONARY, lack of support MUST NOT be used to judge - conformance to this document. This term is also used to hint of a - possible status change in the future to MANDATORY. - - OBSOLETE: New implementations SHOULD NOT support this algorithm. - - These words are also defined in - [I-D.ogud-iana-protocol-maintenance-words], but the definitions above - - - -Rose Expires December 20, 2010 [Page 3] - -Internet-Draft IANA Registry Fixes June 2010 - - - are used for this document. - -1.2. Requirements Language - - 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 [RFC2119]. - -2. DNS Security Algorithm Number Subregistry Fixes - - 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. - - 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 [RFC4034] with updates - for algorithms specified after the original DNSSEC specification. - The status of algorithms marked OPTIONAL in [RFC4034] are changed to - DISCRETIONARY as defined in - [I-D.ogud-iana-protocol-maintenance-words]. The status of algorithms - marked NOT RECOMMENDED in [RFC4034] are changed to OBSOLETE as - defined in [I-D.ogud-iana-protocol-maintenance-words]. - -2.1. Individual Fixes - - This document changes three entries in the Domain Name System - Security (DNSSEC) Algorithm Registry. They are: - - The description for assignment number 4 is changed to "Reserved until - 2020". - - The description for assignment number 9 is changed to "Reserved until - 2020". - - The description for assignment number 11 is changed to "Reserved - until 2020". - - Registry entries 13-251 remains Unassigned. - - 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). - - - - -Rose Expires December 20, 2010 [Page 4] - -Internet-Draft IANA Registry Fixes June 2010 - - -2.2. Updated Registry Snapshot - - As of the current time, the DNS Security Algorithm Number subregistry - would look like the following: - - Zone Trans -Number Description Mnem. Sign Sign Status Reference ------- ----------- ------ ---- ----- ------------ --------- - 0 Reserved [RFC4398] - 1 RSA/MD5 RSAMD5 N Y OBSOLETE [RFC4034], - [RFC3110] - (this memo) - 2 Diffie-Hellman DH N Y OPTIONAL [RFC2539] - (this memo) - 3 DSA/SHA-1 DSASHA1 Y Y OPTIONAL [RFC2536], - [RFC4034], - FIPS 186-3, - FIPS 180-3 - (this memo) - 4 Reserved until ECC (this memo) - 2020 - 5 RSA/SHA-1 RSASHA1 Y Y MANDATORY [RFC4034] - (this memo) - 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y OPTOINAL [RFC5155] - -SHA1 (this memo) - 7 RSASHA1-NSEC3 RSASHA1- Y Y OPTIONAL [RFC5155] - -SHA1 NSEC3- (this memo) - SHA1 - 8 RSA/SHA-256 RSASHA256 Y * ENCOURAGED [RFC5702] - 9 Reserved until (this memo) - 2020 - 10 RSA/SHA-512 RSASHA512 Y * ENCOURAGED [RFC5702] - (this memo) - 11 Reserved until (this memo) - 2020 - 12 GOST R GOST-ECC Y * OPTIONAL [RFCTBD] - 34.10-2001 (this memo) -13-251 Unassigned - 252 Reserved for INDIRECT N N OPTIONAL [RFC4034] - Indirect keys (this memo) - 253 private PRIVATE Y Y OPTIONAL [RFC4034] - algorithm (this memo) - 254 private PRIVATEOID Y Y OPTIONAL [RFC4034] - algorithm OID (this memo) - 255 Reserved - - - - - - -Rose Expires December 20, 2010 [Page 5] - -Internet-Draft IANA Registry Fixes June 2010 - - -2.3. Specifying New Algorithms and Updating Status of Existing Entries - - [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel - procedure for obtaining an algorithm number for new algorithms other - than a standards track document. Algorithms entered into the - registry using that procedure are always OPTIONAL. - - Adding a newly specified algorithm to the registry with any status - other than OPTIONAL SHALL entail an update of this document in order - to specify new content to the registry. - - Altering the status of any existing algorithm in the registry SHALL - entail an update to this document in order to change the contents of - the registry. - -3. IANA Considerations - - This document seeks to add a column (titled "Status") to the Domain - Name System (DNS) Security Algorithm Numbers registry to indicate - each algorithm's status for implementations seeking to conform to - this document. The new table is in Section 2.2 and includes the - additional following changes detailed in Section 2.1: - - The description of assignment 4 is changed from "Reserved for ECC" to - "Reserved until 2020". - - The description of assignment 9 is changed from "Unassigned" to - "Reserved until 2020". - - The description for assignment number 11 is changed from "Unassigned" - to "Reserved until 2020". - - Registry entries 13-251 remains Unassigned. - - 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. - - 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 relevant content of - the FIPS documents have not changed. - - This draft updates the references of the entries that have an - assigned status, in the table in Section 2.2, the text '(this memo)' - should be replaced with the final RFC when published. - - The Domain Name System (DNS) Security Algorithm Number registry is - - - -Rose Expires December 20, 2010 [Page 6] - -Internet-Draft IANA Registry Fixes June 2010 - - - available at http://www.iana.org/assignments/dns-sec-alg-numbers/ - dns-sec-alg-numbers.xhtml. - -4. Security Considerations - - This document seeks to add a status 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. - -5. References - -5.1. Normative References - - [I-D.ietf-dnsext-dnssec-alg-allocation] Hoffman, P., - "Cryptographic Algorithm - Identifier Allocation for - DNSSEC", draft-ietf- - dnsext-dnssec-alg- - allocation-03 (work in - progress), March 2010. - - [I-D.ogud-iana-protocol-maintenance-words] Gudmundsson, O. and S. - Rose, "Definitions for - expressing standards - requirements in IANA - registries.", draft-ogud- - iana-protocol- - maintenance-words-03 - (work in progress), - January 2010. - - [RFC.TBD] Dolmatov, V., "Use of - GOST signature algorithms - in DNSKEY and RRSIG - Resource Records for - DNSSEC", draft-ietf- - dnsext-dnssec-gost-07 - (work in progress), - March 2010. - - [RFC2119] Bradner, S., "Key words - for use in RFCs to - Indicate Requirement - Levels", BCP 14, - RFC 2119, March 1997. - - [RFC2536] Eastlake, D., "DSA KEYs - - - -Rose Expires December 20, 2010 [Page 7] - -Internet-Draft IANA Registry Fixes June 2010 - - - and SIGs in the Domain - Name System (DNS)", - RFC 2536, March 1999. - - [RFC2539] Eastlake, D., "Storage of - Diffie-Hellman Keys in - the Domain Name System - (DNS)", RFC 2539, - March 1999. - - [RFC3110] Eastlake, D., "RSA/SHA-1 - SIGs and RSA KEYs in the - Domain Name System - (DNS)", RFC 3110, - May 2001. - - [RFC4033] Arends, R., Austein, R., - Larson, M., Massey, D., - and S. Rose, "DNS - Security Introduction and - Requirements", RFC 4033, - March 2005. - - [RFC4034] Arends, R., Austein, R., - Larson, M., Massey, D., - and S. Rose, "Resource - Records for the DNS - Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., - Larson, M., Massey, D., - and S. Rose, "Protocol - Modifications for the DNS - Security Extensions", - RFC 4035, March 2005. - - [RFC4398] Josefsson, S., "Storing - Certificates in the - Domain Name System - (DNS)", RFC 4398, - March 2006. - - [RFC5155] Laurie, B., Sisson, G., - Arends, R., and D. - Blacka, "DNS Security - (DNSSEC) Hashed - Authenticated Denial of - - - -Rose Expires December 20, 2010 [Page 8] - -Internet-Draft IANA Registry Fixes June 2010 - - - Existence", RFC 5155, - March 2008. - - [RFC5702] Jansen, J., "Use of SHA-2 - Algorithms with RSA in - DNSKEY and RRSIG Resource - Records for DNSSEC", - RFC 5702, October 2009. - -5.2. Informative References - - [FIPS.180-3.2008] National Institute of - Standards and Technology, - "Secure Hash Standard", - FIPS PUB 180-3, - October 2008, . - - [FIPS.186-3.2009] National Institute of - Standards and Technology, - "Digital Signature - Standard", FIPS PUB - 186-3, June 2009, . - -Author's Address - - Scott Rose - NIST - 100 Bureau Dr. - Gaithersburg, MD 20899 - USA - - Phone: +1-301-975-8439 - EMail: scottr.nist@gmail.com - - - - - - - - - - - -Rose Expires December 20, 2010 [Page 9] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt new file mode 100644 index 0000000000..5ef96c4273 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt @@ -0,0 +1,448 @@ + + + +DNS Extensions Working Group S. Rose +Internet-Draft NIST +Updates: 2536, 2539, 3110, 4034, August 11, 2010 +4398, 5155, 5702, 5933 +(if approved) +Intended status: Standards Track +Expires: February 12, 2011 + + + Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA + Registry + draft-ietf-dnsext-dnssec-registry-fixes-06 + +Abstract + + The DNS Security Extensions (DNSSEC) requires the use of + cryptographic algorithm suites for generating digital signatures over + DNS data. There is currently an IANA registry for these algorithms + that is incomplete in that it lacks the implementation status of each + algorithm. This document provides an applicability statement on + algorithm status for DNSSEC implementations. This document replaces + that registry table with a new IANA registry table for Domain Name + System Security (DNSSEC) Algorithm Numbers which lists each + algorithm's status based on the current reference. If that status is + not defined in the original specification, this document assigns a + status. + +Status of This Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + + +Rose Expires February 12, 2011 [Page 1] + +Internet-Draft IANA Registry Fixes August 2010 + + + This Internet-Draft will expire on February 12, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 + + 2. The DNS Security Algorithm Number Subregistry . . . . . . . . . 3 + 2.1. Individual Changes . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Domain Name System (DNS) Security Algorithm Number + Registry Table . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Specifying New Algorithms and Updating Status of + Existing Entries . . . . . . . . . . . . . . . . . . . . . 6 + + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + +Rose Expires February 12, 2011 [Page 2] + +Internet-Draft IANA Registry Fixes August 2010 + + +1. Introduction + + The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033], + [RFC4034], and [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). + + The original list of algorithm status is found in [RFC4034]. Other + DNSSEC documents have added new algorithms or changed the status of + algorithms in the registry. However, currently implementors must + read through all the documents in order to discover the current + status of each algorithm in the registry. + + This document replaces the current IANA registry for Domain Name + System Security (DNSSEC) Algorithm Numbers with a newly defined + registry table. This new table (Section 2.2 below) contains a column + that will list the current status of each digital signature algorithm + in the registry at the time of writing and assigns status for some + algorithms used with DNSSEC that did not have an identified status in + their specification. This document updates the following: [RFC2536], + [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and + [RFC5933]. + +1.1. Requirements Language + + 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 [RFC2119]. + +2. The DNS Security Algorithm Number Subregistry + + The DNS Security Algorithm Number subregistry (part of the Domain + Name System (DNS) Security Number registry) will be replaced with the + table below. This table contains a column that contains the current + implementation requirements of the given algorithm. + + There are additional differences 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 [RFC4034] with + updates for algorithms specified after the original DNSSEC + specification. If no status was listed in the original + specification, this document assigns one. + +2.1. Individual Changes + + This document changes three entries in the Domain Name System + Security (DNSSEC) Algorithm Registry. They are: + + + +Rose Expires February 12, 2011 [Page 3] + +Internet-Draft IANA Registry Fixes August 2010 + + + The description for assignment number 4 is changed to "Reserved until + 2020". + + The description for assignment number 9 is changed to "Reserved until + 2020". + + The description for assignment number 11 is changed to "Reserved + until 2020". + + Registry entries 13-251 remains Unassigned. + + The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to + RECOMMENDED and OPTIONAL respectively. The difference is due to the + fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL. The + status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED 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). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires February 12, 2011 [Page 4] + +Internet-Draft IANA Registry Fixes August 2010 + + +2.2. Domain Name System (DNS) Security Algorithm Number Registry Table + + The Domain Name System (DNS) Security Algorithm Number registry is + hereby specified as follows: + + Zone Transaction +Number Description Mnemonic Sign Sign Status Reference +------ ----------- ------ ---- ----- ------------ --------- + 0 Reserved [RFC4398] + 1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC4034], + IMPLEMENT [RFC3110] + (this memo) + 2 Diffie-Hellman DH N Y [RFC2539] + (this memo) + 3 DSA/SHA-1 DSASHA1 Y Y [RFC2536], + [RFC4034], + FIPS 186-3, + FIPS 180-3 + (this memo) + 4 Reserved until ECC (this memo) + 2020 + 5 RSA/SHA-1 RSASHA1 Y Y REQUIRED [RFC4034] + (this memo) + 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155] + -SHA1 (this memo) + 7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155] + -SHA1 NSEC3- (this memo) + SHA1 + 8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702] + (this memo) + 9 Reserved until (this memo) + 2020 + 10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702] + (this memo) + 11 Reserved until (this memo) + 2020 + 12 GOST R GOST-ECC Y * [RFC5933] + 34.10-2001 (this memo) +13-251 Unassigned + 252 Reserved for INDIRECT N N [RFC4034] + Indirect keys (this memo) + 253 private PRIVATE Y Y [RFC4034] + algorithm (this memo) + 254 private PRIVATEOID Y Y [RFC4034] + algorithm OID (this memo) + 255 Reserved + + + + + +Rose Expires February 12, 2011 [Page 5] + +Internet-Draft IANA Registry Fixes August 2010 + + +2.3. Specifying New Algorithms and Updating Status of Existing Entries + + [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel + procedure for obtaining an algorithm number for new algorithms other + than a standards track document. Algorithms entered into the + registry using that procedure do not have a listed status. + Specifications that follow this path do not need to obsolete or + update this document. + + Adding a newly specified algorithm to the registry with a status + SHALL entail obsoleting this document and replacing the registry + table (with the new algorithm entry). Altering the status column + value of any existing algorithm in the registry SHALL entail + obsoleting this document and replacing the registry table. + + This document cannot be updated, only made obsolete and replaced by a + successor document. + +3. IANA Considerations + + This document replaces the Domain Name System (DNS) Security + Algorithm Numbers registry. The new registry table is in Section + 2.2. + + The original 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. + +4. Security Considerations + + This document replaces the Domain Name System (DNS) Security + Algorithm Numbers registry. It is not meant to be a discussion on + algorithm superiority. No new security considerations are raised in + this document. + +5. References + +5.1. Normative References + + [I-D.ietf-dnsext-dnssec-alg-allocation] Hoffman, P., "Cryptographic + Algorithm Identifier + Allocation for DNSSEC", draf + t-ietf-dnsext-dnssec-alg- + allocation-03 (work in + progress), March 2010. + + [RFC2119] Bradner, S., "Key words for + use in RFCs to Indicate + + + +Rose Expires February 12, 2011 [Page 6] + +Internet-Draft IANA Registry Fixes August 2010 + + + Requirement Levels", BCP 14, + RFC 2119, March 1997. + + [RFC2536] Eastlake, D., "DSA KEYs and + SIGs in the Domain Name + System (DNS)", RFC 2536, + March 1999. + + [RFC2539] Eastlake, D., "Storage of + Diffie-Hellman Keys in the + Domain Name System (DNS)", + RFC 2539, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 + SIGs and RSA KEYs in the + Domain Name System (DNS)", + RFC 3110, May 2001. + + [RFC4033] Arends, R., Austein, R., + Larson, M., Massey, D., and + S. Rose, "DNS Security + Introduction and + Requirements", RFC 4033, + March 2005. + + [RFC4034] Arends, R., Austein, R., + Larson, M., Massey, D., and + S. Rose, "Resource Records + for the DNS Security + Extensions", RFC 4034, + March 2005. + + [RFC4035] Arends, R., Austein, R., + Larson, M., Massey, D., and + S. Rose, "Protocol + Modifications for the DNS + Security Extensions", + RFC 4035, March 2005. + + [RFC4398] Josefsson, S., "Storing + Certificates in the Domain + Name System (DNS)", + RFC 4398, March 2006. + + [RFC5155] Laurie, B., Sisson, G., + Arends, R., and D. Blacka, + "DNS Security (DNSSEC) + Hashed Authenticated Denial + + + +Rose Expires February 12, 2011 [Page 7] + +Internet-Draft IANA Registry Fixes August 2010 + + + of Existence", RFC 5155, + March 2008. + + [RFC5702] Jansen, J., "Use of SHA-2 + Algorithms with RSA in + DNSKEY and RRSIG Resource + Records for DNSSEC", + RFC 5702, October 2009. + + [RFC5933] Dolmatov, V., Chuprina, A., + and I. Ustinov, "Use of GOST + Signature Algorithms in + DNSKEY and RRSIG Resource + Records for DNSSEC", + RFC 5933, July 2010. + +5.2. Informative References + + [FIPS.180-3.2008] National Institute of + Standards and Technology, + "Secure Hash Standard", + FIPS PUB 180-3, + October 2008, . + + [FIPS.186-3.2009] National Institute of + Standards and Technology, + "Digital Signature + Standard", FIPS PUB 186-3, + June 2009, . + +Author's Address + + Scott Rose + NIST + 100 Bureau Dr. + Gaithersburg, MD 20899 + USA + + Phone: +1-301-975-8439 + EMail: scottr.nist@gmail.com + + + + + +Rose Expires February 12, 2011 [Page 8] +