Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6014 VPN Consortium
Updates: 4033, 4034, 4035 November 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6014 VPN Consortium
Updates: 4033, 4034, 4035 November 2010
Category: Standards Track
ISSN: 2070-1721
Cryptographic Algorithm Identifier Allocation for DNSSEC
DNSSEC的密码算法标识符分配
Abstract
摘要
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations.
本文件规定了IANA注册表中DNSSEC加密算法标识符的分配方式。它将要求从“标准要求”更改为“RFC要求”。它不会更改DNSSEC实施所建议或要求的算法列表。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6014.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6014.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
[RFC2535] specifies that the IANA registry for DNS Security Algorithm Numbers be updated by IETF Standards Action only, with the exception of two values -- 253 and 254. In essence, this means that for an algorithm to get its own entry in the registry, the algorithm must be defined in an RFC on the Standards Track as defined in [RFC2026]. The requirement from RFC 2535 is repeated in [RFC3755] and the combination of [RFC4033], [RFC4034], and [RFC4035].
[RFC2535]指定仅通过IETF标准操作更新DNS安全算法编号的IANA注册表，但两个值（253和254）除外。本质上，这意味着算法要在注册表中获得自己的条目，必须在[RFC2026]中定义的标准轨道上的RFC中定义算法。[RFC3755]以及[RFC4033]、[RFC4034]和[RFC4035]的组合中重复了RFC 2535的要求。
RFC 2535 allows algorithms that are not on the Standards Track to use private values 253 and 254 in signatures. In each case, an unregistered private name must be included with each use of the algorithm in order to differentiate different algorithms that use the value.
RFC 2535允许不在标准轨道上的算法在签名中使用私有值253和254。在每种情况下，每次使用算法时都必须包含一个未注册的私有名称，以便区分使用该值的不同算法。
2. Requirements for Assignments in the DNS Security Algorithm Numbers Registry
2. DNS安全算法编号注册表中的分配要求
This document changes the requirement for registration from requiring a Standards Track RFC to requiring a published RFC of any type. There are two reasons for relaxing the requirement:
本文件将注册要求从要求标准跟踪RFC更改为要求发布任何类型的RFC。放宽这项规定有两个原因：
o There are some algorithms that are useful that may not be able to be in a Standards Track RFC. For any number of reasons, an algorithm might not have been evaluated thoroughly enough to be able to be put on the Standards Track. Another example is that the algorithm might have unclear intellectual property rights that prevents the algorithm from being put on the Standards Track.
o 有些有用的算法可能无法用于标准跟踪RFC。由于各种原因，算法的评估可能不够彻底，无法纳入标准轨道。另一个例子是，该算法可能拥有不明确的知识产权，这妨碍了该算法被纳入标准轨道。
o Although the size of the registry is restricted (about 250 entries), new algorithms are proposed infrequently. It could easily be many decades before there is any reason to consider restricting the registry again.
o 尽管注册表的大小受到限制（大约250个条目），但很少提出新的算法。很容易在几十年前就有理由考虑再次限制注册表。
Some developers will care about the standards level of the RFCs that are in the registry. The registry has been updated to reflect the current standards level of each algorithm listed.
一些开发人员会关心注册表中RFC的标准级别。注册表已更新，以反映列出的每个算法的当前标准级别。
To address concerns about the registry eventually filling up, the IETF should re-evaluate the requirements for entry into this registry when approximately 120 of the registry entries have been assigned. That evaluation may lead to tighter restrictions or a new mechanism for extending the size of the registry. In order to make this evaluation more likely, IANA has marked about half of the currently available entries as "Reserved" in order to make the timing for that re-evaluation more apparent.
为了解决有关注册表最终填充的问题，IETF应在分配了大约120个注册表条目后重新评估进入该注册表的要求。这种评估可能会导致更严格的限制或一种扩展注册表大小的新机制。为了使这一评估更有可能进行，IANA已将当前可用条目中的大约一半标记为“保留”，以便使重新评估的时间更加明确。
The private-use values, 253 and 254, are still useful for developers who want to test, in private, algorithms for which there is no RFC. This document does not change the semantics of those two values.
私有使用值253和254对于希望私下测试没有RFC的算法的开发人员仍然有用。本文档不会更改这两个值的语义。
It is important to note that, according to RFC 4034, DNSSEC implementations are not expected to include all of the algorithms listed in the IANA registry; in fact, RFC 4034 and the IANA registry list an algorithm that implementations should not include. This document does nothing to change the expectation that there will be items listed in the IANA registry that need not be (and in some cases, should not be) included in all implementations.
需要注意的是，根据RFC 4034，DNSSEC实施不应包括IANA注册表中列出的所有算法；事实上，RFC4034和IANA注册表列出了实现中不应包含的算法。本文档并没有改变IANA注册表中列出的项目不需要（在某些情况下，不应该）包含在所有实现中的期望。
There are many reasons why a DNSSEC implementation might not include one or more of the algorithms listed, even those on the Standards Track. In order to be compliant with RFC 4034, an implementation only needs to implement the algorithms listed as mandatory to implement in that standard, or updates to that standard. This document does nothing to change the list of mandatory-to-implement algorithms in RFC 4034. This document does not change the requirements for when an algorithm becomes mandatory to implement. Such requirements should come in a separate, focused document.
DNSSEC实现可能不包括列出的一个或多个算法，甚至是标准轨道上的算法，原因有很多。为了符合RFC 4034，实现只需要实现该标准中列出的强制实现的算法，或对该标准的更新。本文件不改变RFC 4034中实现算法的强制列表。本文件不改变强制实施算法的要求。此类要求应包含在一份单独的重点文件中。
It should be noted that the order of algorithms in the IANA registry does not signify or imply cryptographic strength or preference.
应该注意的是，IANA注册表中的算法顺序并不表示或暗示加密强度或优先权。
This document updates allocation requirements for unassigned values in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry located at http://www.iana.org/assignments/ dns-sec-alg-numbers, in the sub-registry titled "DNS Security Algorithm Numbers". The registration procedure for values that are assigned after this document is published is "RFC Required".
本文档更新了“域名系统安全（DNSSEC）算法编号”注册表中未分配值的分配要求，该注册表位于http://www.iana.org/assignments/ dns sec alg编号，位于名为“dns安全算法编号”的子注册表中。本文件发布后分配的值的注册程序为“要求RFC”。
IANA has marked values 123 through 251 as "Reserved". The registry notes that this reservation is made in RFC 6014 (this RFC) so that when most of the unreserved values are taken, future users and IANA will have a pointer to where the reservation originated and its purpose.
IANA将值123到251标记为“保留”。注册中心注意到，此保留是在RFC 6014（此RFC）中进行的，因此，当获取大多数未保留的值时，未来用户和IANA将有一个指向保留来源及其用途的指针。
IANA has added a textual notation to the "References" column in the registry that gives the current standards status for each RFC that is listed in the registry.
IANA在注册表中的“参考”列中添加了一个文本符号，该符号给出了注册表中列出的每个RFC的当前标准状态。
An algorithm described in an RFC that is not on the Standards Track may have weaker security than one that is on the Standards Track; in fact, that may be the reason that the algorithm was not allowed on Standards Track. Note, however, that not being on the Standards Track does not necessarily mean that an algorithm is weaker. Conversely, algorithms that are on the Standards Track should not necessarily be considered better than algorithms that are not on the Standards Track. There are other reasons (such as intellectual property concerns) that can keep algorithms that are widely considered to be strong off the Standards Track.
在RFC中描述的不在标准轨道上的算法可能比在标准轨道上的算法具有较弱的安全性；事实上，这可能是该算法在标准轨道上不被允许的原因。但是，请注意，不在标准轨道上并不一定意味着算法较弱。相反，在标准轨道上的算法不一定比不在标准轨道上的算法更好。还有其他原因（如知识产权问题）可以使被广泛认为强大的算法偏离标准轨道。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755]Weiler，S.“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
During the early discussion of this document, it was proposed that maybe there should be a small number of values reserved for "experimental" purposes. This proposal was not included in this document because of the long history in the IETF of experimental values that became permanent. That is, a developer would release (maybe "experimentally") a version of software that had the experimental value associated with a particular extension, competitors would code their systems to test interoperability, and then no one wanted to change the values in their software to the "real" value that was later assigned.
在本文件的早期讨论中，有人建议，可能应该保留少量值用于“实验”目的。由于IETF中长期存在永久性的实验值，因此本提案未包含在本文件中。也就是说，开发人员将发布（可能是“实验性的”）具有与特定扩展相关的实验值的软件版本，竞争对手将对其系统进行编码以测试互操作性，然后没有人希望将其软件中的值更改为后来分配的“真实”值。
There was also a proposal that IANA should reserve two values to be used in documentation only, similar to the way that "example.com" has been reserved as a domain name. That proposal was also not included in this document because all values need to be associated with some algorithm, and there is no problem with having examples that point to commonly deployed algorithms.
还有一项建议是，IANA应保留两个值，仅在文档中使用，类似于将“example.com”保留为域名的方式。该建议也未包含在本文档中，因为所有值都需要与某个算法关联，并且有指向常用部署算法的示例也没有问题。
Author's Address
作者地址
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org