RFC 6014 - Cryptographic Algorithm Identifier Allocation for DNSSEC 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6014
タイトル : RFC 6014 - DNSSECの暗号アルゴリズム識別子の割り当て
翻訳編集 : 自動生成

[要約] RFC 6014は、DNSSEC（Domain Name System Security Extensions）で使用される暗号アルゴリズム識別子の割り当てに関するプロセスを定義しています。この文書の目的は、DNSSECのセキュリティを強化するために使用される暗号アルゴリズムの識別子を管理し、割り当てるための一貫した方法を提供することです。DNSSECは、DNS情報の改ざんを防ぐためにデジタル署名を使用し、そのプロセスの中で特定の暗号アルゴリズムが必要とされます。RFC 6014は、これらのアルゴリズム識別子の割り当てと管理に関するガイドラインを提供します。関連するRFCには、DNSSECの基本を定義するRFC 4033、RFC 4034、RFC 4035などがあります。

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.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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で入手できます。

著作権表示

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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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として、またはそれを英語以外の言語に翻訳するための出版物。

1. Introduction

1. はじめに

[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]は、DNSセキュリティアルゴリズム番号のIANAレジストリがIETF標準アクションによってのみ更新されることを指定します。ただし、253と254の2つの値を除きます。つまり、これは、アルゴリズムがレジストリに独自のエントリを取得することを意味します。、アルゴリズムは[RFC2026]で定義されているように、Standards TrackのRFCで定義する必要があります。 RFC 2535の要件は、[RFC3755]と[RFC4033]、[RFC4034]、および[RFC4035]の組み合わせで繰り返されています。

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を使用すると、Standards Trackにないアルゴリズムで、署名にプライベート値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:

このドキュメントは、登録の要件を、Standards Track RFCの要求から、あらゆるタイプの公開されたRFCの要求に変更します。要件を緩和する理由は2つあります。

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 Standards Track 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.

レジストリが最終的にいっぱいになることに関する懸念に対処するには、約120のレジストリエントリが割り当てられたときに、IETFがこのレジストリへのエントリの要件を再評価する必要があります。その評価は、より厳しい制限またはレジストリのサイズを拡張するための新しいメカニズムにつながる可能性があります。この評価をより可能にするために、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.

private-useの値である253および254は、RFCが存在しないアルゴリズムをプライベートでテストしたい開発者には依然として役立ちます。このドキュメントでは、これら2つの値のセマンティクスは変更されません。

3. Expectations for Implementations

3. 実装への期待

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レジストリにリストされているすべてのアルゴリズムが含まれているとは限らないことに注意することが重要です。実際、RFC 4034と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の実装に、標準トラックのアルゴリズムも含めて、リストされているアルゴリズムの1つ以上が含まれない場合がある理由は多数あります。 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レジストリ内のアルゴリズムの順序は、暗号化の強度や設定を意味したり示唆したりするものではないことに注意してください。

4. IANA Considerations

4. 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".

このドキュメントでは、http：//www.iana.org/assignments/dns-sec-alg-numbersにある「ドメインネームシステムセキュリティ（DNSSEC）アルゴリズム番号」レジストリのサブレジストリの未割り当て値の割り当て要件を更新しています。「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の現在の標準ステータスを示すレジストリの「参照」列にテキスト表記を追加しました。

5. Security Considerations

5. セキュリティに関する考慮事項

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に記述されているアルゴリズムは、標準トラックにあるアルゴリズムよりもセキュリティが弱い場合があります。実際、これがアルゴリズムが標準化過程で許可されなかった理由かもしれません。ただし、標準化過程にないからといって、必ずしもアルゴリズムが弱いことを意味するわけではありません。逆に、スタンダードトラックにあるアルゴリズムは、スタンダードトラックにないアルゴリズムよりも優れているとは限りません。広く知られているアルゴリズムを標準化軌道から遠ざける可能性がある他の理由（知的財産の懸念など）があります。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC2535] Eastlake、D。、「ドメインネームシステムのセキュリティ拡張機能」、RFC 2535、1999年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 Security Extensionsのリソースレコード」、RFC 4034、2005年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月。

6.2. Informative References

6.2. 参考引用

[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月。

Appendix A. Experimental and Documentation Values

付録A.実験値とドキュメント値

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.

「example.com」がドメイン名として予約されているのと同じように、IANAがドキュメントでのみ使用される2つの値を予約するという提案もありました。すべての値はいくつかのアルゴリズムに関連付ける必要があるため、この提案にはこの提案も含まれていません。また、一般的に展開されているアルゴリズムを指す例があっても問題はありません。

Author's Address

著者のアドレス

Paul Hoffman VPN Consortium

ポールホフマンVPNコンソーシアム

   EMail: paul.hoffman@vpnc.org