--- /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
projects / thirdparty / bind9.git / commitdiff
