+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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, <http://
- csrc.nist.gov/
- publications/fips/
- fips180-3/fips180-3.pdf>.
-
- [FIPS.186-3.2009] National Institute of
- Standards and Technology,
- "Digital Signature
- Standard", FIPS PUB
- 186-3, June 2009, <http:/
- /csrc.nist.gov/
- publications/fips/
- fips186-3/
- fips_186-3.pdf>.
-
-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]
-\f
--- /dev/null
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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, <http://
+ csrc.nist.gov/publications/
+ fips/fips180-3/
+ fips180-3.pdf>.
+
+ [FIPS.186-3.2009] National Institute of
+ Standards and Technology,
+ "Digital Signature
+ Standard", FIPS PUB 186-3,
+ June 2009, <http://
+ csrc.nist.gov/publications/
+ fips/fips186-3/
+ fips_186-3.pdf>.
+
+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]
+\f
projects / thirdparty / bind9.git / commitdiff
