From: Automatic Updater Date: Sat, 19 Jun 2010 01:33:28 +0000 (+0000) Subject: sync X-Git-Tag: v9.5.3b1~50 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=099a72ea3b5f4db7f976d89647ae20bbb2a9cfb6;p=thirdparty%2Fbind9.git sync --- diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt new file mode 100644 index 00000000000..8f63c1f2691 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-05.txt @@ -0,0 +1,504 @@ + + + +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] +