RFC3445 日本語訳

Network Working Group                                          D. Massey
Request for Comments: 3445                                       USC/ISI
Updates: 2535                                                    S. Rose
Category: Standards Track                                           NIST
                                                           December 2002

コメントを求めるワーキンググループD.マッシー要求をネットワークでつないでください: 3445のUSC/ISIアップデート: 2535秒間バラカテゴリ: 標準化過程NIST2002年12月

           Limiting the Scope of the KEY Resource Record (RR)

主要なリソース記録の範囲を制限します。(RR)

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document limits the Domain Name System (DNS) KEY Resource Record
   (RR) to only keys used by the Domain Name System Security Extensions
   (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
   keys and arbitrary application keys.  Storing both DNSSEC and
   application keys with the same record type is a mistake.  This
   document removes application keys from the KEY record by redefining
   the Protocol Octet field in the KEY RR Data.  As a result of removing
   application keys, all but one of the flags in the KEY record become
   unnecessary and are redefined.  Three existing application key sub-
   types are changed to reserved, but the format of the KEY record is
   not changed.  This document updates RFC 2535.

このドキュメントはドメインネームシステム(DNS)KEY Resource Record(RR)をドメインネームシステムSecurity Extensions(DNSSEC)によって使用されたキーだけに制限します。 オリジナルのKEY RRは、DNSSECキーと任意のアプリケーションキーの両方を保存するのにサブタイプを使用しました。 同じレコード種類でDNSSECとアプリケーションキーの両方を保存するのは、誤りです。 このドキュメントは、KEY RR DataでKEY記録からプロトコルOctet分野を再定義することによって、アプリケーションキーを取り除きます。 アプリケーションキーを取り除くことの結果、KEY記録の旗の1つ以外のすべてが、不要になって、再定義されます。 3つの既存のアプリケーションキーサブタイプに予約されていた状態で変えますが、KEY記録の形式は変えません。 このドキュメントはRFC2535をアップデートします。

1. Introduction

1. 序論

   This document limits the scope of the KEY Resource Record (RR).  The
   KEY RR was defined in [3] and used resource record sub-typing to hold
   arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
   This document eliminates the existing Email, IPSEC, and TLS sub-types
   and prohibits the introduction of new sub-types.  DNSSEC will be the
   only allowable sub-type for the KEY RR (hence sub-typing is
   essentially eliminated) and all but one of the KEY RR flags are also
   eliminated.

このドキュメントはKEY Resource Record(RR)の範囲を制限します。 KEY RRは[3]で定義されて、リソースの記録のサブタイプしているメールや、IPSECや、DNSSECや、TLSなどの任意の公開鍵を保持するためにキーを使用しました。 このドキュメントは、既存のメール、IPSEC、およびTLSサブタイプを排除して、新しいサブタイプの導入を禁止します。 DNSSECはKEY RRのために唯一の許容できるサブタイプになるでしょう、そして、(したがって、サブタイプは本質的には排除されます)また、KEY RR旗の1つ以外のすべてが排除されます。

Massey & Rose               Standards Track                     [Page 1]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[1ページ]RFC3445

   Section 2 presents the motivation for restricting the KEY record and
   Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
   changes from RFC 2535 and discuss backwards compatibility.  It is
   important to note that this document restricts the use of the KEY RR
   and simplifies the flags, but does not change the definition or use
   of DNSSEC keys.

セクション2はKEY記録を制限することに関する動機を提示します、そして、セクション3は改訂されたKEY RRを定義します。 セクション4と5は、RFC2535から変化をまとめて、逆に互換性について論じます。 このドキュメントがKEY RRの使用を制限して、旗を簡素化しますが、DNSSECキーの定義か使用を変えないことに注意するのは重要です。

   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 RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?

2. Motivation for Restricting the KEY RR

2. 主要なRRを制限することに関する動機

   The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
   Algorithm type, and a Public Key.  The Protocol Octet identifies the
   KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
   Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
   stored in the KEY RR and used Protocol Octet values of 1,2, and 4
   (respectively).  Protocol Octet values 5-254 were available for
   assignment by IANA and values were requested (but not assigned) for
   applications such as SSH.

KEY RR RDATA[3]はFlags、プロトコルOctet、Algorithmタイプ、およびPublic Keyから成ります。 プロトコルOctetはKEY RRサブタイプを特定します。 DNSSEC公開鍵は、KEY RRに3のプロトコルOctet価値を使用することで保存されます。 メール、IPSEC、およびTLSキーは、また、KEY RRに保存されて、1、2、および4のプロトコルOctet値を使用しました(それぞれ)。 プロトコルOctet値5-254はIANAによる課題に利用可能でした、そして、値はSSHなどのアプリケーションのために要求されました(しかし、割り当てられません)。

   Any use of sub-typing has inherent limitations.  A resolver can not
   specify the desired sub-type in a DNS query and most DNS operations
   apply only to resource records sets.  For example, a resolver can not
   directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
   has to request all KEY RRs associated with a DNS name and then search
   the set for the desired DNSSEC sub-type.  DNSSEC signatures also
   apply to the set of all KEY RRs associated with the DNS name,
   regardless of sub-type.

サブタイプのどんな使用にも、固有の制限があります。 レゾルバはDNS質問で必要なサブタイプを指定できません、そして、ほとんどのDNS操作がリソース記録セットだけに適用されます。 例えば、レゾルバは直接DNSSEC subtype KEY RRsを要求できません。 代わりに、レゾルバは、すべてのKEY RRsが必要なDNSSECサブタイプのためにDNS名と当時の検索にセットを関連づけたよう要求しなければなりません。 また、DNSSEC署名はサブタイプにかかわらずDNS名に関連しているすべてのKEY RRsのセットに適用されます。

   In the case of the KEY RR, the inherent sub-type limitations are
   exacerbated since the sub-type is used to distinguish between DNSSEC
   keys and application keys.  DNSSEC keys and application keys differ
   in virtually every respect and Section 2.1 discusses these
   differences in more detail.  Combining these very different types of
   keys into a single sub-typed resource record adds unnecessary
   complexity and increases the potential for implementation and
   deployment errors.  Limited experimental deployment has shown that
   application keys stored in KEY RRs are problematic.

KEY RRの場合では、サブタイプがDNSSECキーとアプリケーションキーを見分けるのに使用されるので、固有のサブタイプ制限は悪化させられます。 DNSSECキーとアプリケーションキーは実際にはあらゆる点において異なります、そして、セクション2.1はさらに詳細にこれらの違いについて議論します。 これらの非常に異なったタイプのキーをただ一つのサブタイプされたリソース記録に結合すると、不要な複雑さが加えられて、実装と展開誤りの可能性は増強されます。 限られた実験的な展開は、KEY RRsに保存されたアプリケーションキーが問題が多いのを示しました。

   This document addresses these issues by removing all application keys
   from the KEY RR.  Note that the scope of this document is strictly
   limited to the KEY RR and this document does not endorse or restrict
   the storage of application keys in other, yet undefined, resource
   records.

このドキュメントは、KEY RRからすべてのアプリケーションキーを取り除くことによって、これらの問題を扱います。 このドキュメントの範囲が厳密にKEY RRに制限されて、このドキュメントが他の、そして、しかし、未定義のリソース記録における、アプリケーションキーのストレージを是認もしませんし、制限もしないことに注意してください。

Massey & Rose               Standards Track                     [Page 2]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[2ページ]RFC3445

2.1 Differences Between DNSSEC and Application Keys

2.1 DNSSECとアプリケーションキーの違い

   DNSSEC keys are an essential part of the DNSSEC protocol and are used
   by both name servers and resolvers in order to perform DNS tasks.  A
   DNS zone key, used to sign and authenticate RR sets, is the most
   common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
   DNSSEC keys.

DNSSECキーは、DNSSECプロトコルの不可欠の部分であり、DNSタスクを実行するのにネームサーバとレゾルバの両方によって使用されます。 RRセットに署名して、認証するのに使用されるDNSゾーンキーはDNSSECキーの最も一般的な例です。 また、SIG(0)[4]とTKEY[3]はDNSSECキーを使用します。

   Application keys such as Email keys, IPSEC keys, and TLS keys are
   simply another type of data.  These keys have no special meaning to a
   name server or resolver.

メールキーや、IPSECキーや、TLSキーなどのアプリケーションキーは単に別のタイプに関するデータです。 これらのキーはどんな特別な意味もネームサーバかレゾルバに持っていません。

   The following table summarizes some of the differences between DNSSEC
   keys and application keys:

以下のテーブルはDNSSECキーとアプリケーションキーの違いのいくつかをまとめます:

      1.  They serve different purposes.

1. それらは異なる役割に役立ちます。

      2.  They are managed by different administrators.

2. それらは異なった管理者によって管理されます。

      3.  They are authenticated according to different rules.

3. 異なった規則に従って、それらは認証されます。

      4.  Nameservers use different rules when including them in
          responses.

4. 含んでいるそれらであるときに、ネームサーバは応答に異なった規則を使用します。

      5.  Resolvers process them in different ways.

5. レゾルバは異なった方法で彼らを処理します。

      6.  Faults/key compromises have different consequences.

6. 欠点/主要な感染には、異なった結果があります。

   1.  The purpose of a DNSSEC key is to sign resource records
   associated with a DNS zone (or generate DNS transaction signatures in
   the case of SIG(0)/TKEY).  But the purpose of an application key is
   specific to the application.  Application keys, such as PGP/email,
   IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
   the purpose and proper use of application keys is outside the scope
   of DNS.

1. DNSSECキーの目的はDNSゾーンに関連しているリソース記録に署名する(SIG(0)/TKEYの場合でDNSがトランザクション署名であると生成してください)ことです。 しかし、アプリケーションキーの目的はアプリケーションに特定です。 PGP/メールなどのアプリケーションキー(IPSEC、TLS、およびSSHキー)は、どんなゾーンと目的の義務的な部分ではありません、そして、DNSの範囲の外にアプリケーションキーの適切な使用があります。

   2.  DNSSEC keys are managed by DNS administrators, but application
   keys are managed by application administrators.  The DNS zone
   administrator determines the key lifetime, handles any suspected key
   compromises, and manages any DNSSEC key changes.  Likewise, the
   application administrator is responsible for the same functions for
   the application keys related to the application.  For example, a user
   typically manages her own PGP key and a server manages its own TLS
   key.  Application key management tasks are outside the scope of DNS
   administration.

2. DNSSECキーはDNS管理者によって管理されますが、アプリケーションキーはアプリケーション管理者によって管理されます。 DNSゾーンの管理者は、主要な生涯を決定して、どんな疑われた主要な感染も扱って、どんなDNSSECキーチェンジも管理します。 同様に、アプリケーションに関連するアプリケーションキーにおいて、アプリケーション管理者は同じ機能に責任があります。 例えば、ユーザは彼女自身のPGPキーを通常管理します、そして、サーバはそれ自身のTLSキーを管理します。 DNS管理の範囲の外にアプリケーションキー管理タスクがあります。

Massey & Rose               Standards Track                     [Page 3]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[3ページ]RFC3445

   3.  DNSSEC zone keys are used to authenticate application keys, but
   by definition, application keys are not allowed to authenticate DNS
   zone keys.  A DNS zone key is either configured as a trusted key or
   authenticated by constructing a chain of trust in the DNS hierarchy.
   To participate in the chain of trust, a DNS zone needs to exchange
   zone key information with its parent zone [3].  Application keys are
   not configured as trusted keys in the DNS and are never part of any
   DNS chain of trust.  Application key data is not needed by the parent
   and does not need to be exchanged with the parent zone for secure DNS
   resolution to work.  A resolver considers an application key RRset as
   authenticated DNS information if it has a valid signature from the
   local DNS zone keys, but applications could impose additional
   security requirements before the application key is accepted as
   authentic for use with the application.

3. DNSSECゾーンキーはアプリケーションキーを認証するのに使用されますが、定義上、アプリケーションキーはDNSゾーンキーを認証できません。 DNSゾーンキーは、DNS階層構造で信じられたキーとして構成されるか、または信頼のチェーンを組み立てることによって、認証されます。 信頼のチェーンに参加するために、DNSゾーンは、親ゾーン[3]とゾーンの主要な情報を交換する必要があります。 アプリケーションキーは、信じられたキーとしてDNSで構成されないで、また決して信頼のどんなDNSチェーンの一部ではありません。 アプリケーションキーデータによって親は必要でなく、親ゾーンで働く安全なDNS解決と交換される必要はありません。 それに地方のDNSゾーンキーからの有効な署名があるなら、レゾルバは、認証されたDNS情報としてアプリケーションキーがRRsetであると考えますが、アプリケーションキーが使用に正統であるとしてアプリケーションで認められる前にアプリケーションは追加担保要件を課すかもしれません。

   4.  It may be useful for nameservers to include DNS zone keys in the
   additional section of a response, but application keys are typically
   not useful unless they have been specifically requested.  For
   example, it could be useful to include the example.com zone key along
   with a response that contains the www.example.com A record and SIG
   record.  A secure resolver will need the example.com zone key in
   order to check the SIG and authenticate the www.example.com A record.
   It is typically not useful to include the IPSEC, email, and TLS keys
   along with the A record.  Note that by placing application keys in
   the KEY record, a resolver would need the IPSEC, email, TLS, and
   other key associated with example.com if the resolver intends to
   authenticate the example.com zone key (since signatures only apply to
   the entire KEY RR set).  Depending on the number of protocols
   involved, the KEY RR set could grow unwieldy for resolvers, and DNS
   administrators to manage.

4. ネームサーバが応答の追加セクションにDNSゾーンキーを含んでいるのが、役に立つかもしれませんが、それらが明確に要求されていないなら、アプリケーションキーは通常役に立ちません。 例えば、www.example.com A記録とSIG記録を含む応答と共に主要なexample.comゾーンを含んでいるのは役に立つかもしれません。 安全なレゾルバは、SIGをチェックして、www.example.com A記録を認証するためにexample.comゾーンキーを必要とするでしょう。 A記録に伴うIPSEC、メール、およびTLSキーを含んでいるのは通常役に立ちません。 レゾルバがexample.comゾーンキーを認証するつもりであるなら(署名が全体のKEY RRセットに適用されるだけであるので)KEY記録にアプリケーションキーを置くことによって、レゾルバがexample.comに関連しているIPSEC、メール、TLS、および他のキーを必要とすることに注意してください。 プロトコルのかかわった数によって、KEY RRセットは管理するレゾルバ、およびDNS管理者にとって扱いにくくなることができました。

   5.  DNS zone keys require special handling by resolvers, but
   application keys are treated the same as any other type of DNS data.
   The DNSSEC keys are of no value to end applications, unless the
   applications plan to do their own DNS authentication.  By definition,
   secure resolvers are not allowed to use application keys as part of
   the authentication process.  Application keys have no unique meaning
   to resolvers and are only useful to the application requesting the
   key.  Note that if sub-types are used to identify the application
   key, then either the interface to the resolver needs to specify the
   sub-type or the application needs to be able to accept all KEY RRs
   and pick out the desired sub-type.

5. DNSゾーンキーはレゾルバで特別な取り扱いを必要としますが、アプリケーションキーは同じようにいかなる他のタイプに関するDNSデータとしても扱われます。 DNSSECキーには、アプリケーションが、それら自身のDNS認証をするのを計画していないなら、アプリケーションを終わらせるために、価値が全くありません。 定義上、安全なレゾルバは認証過程の一部としてアプリケーションキーを使用できません。 アプリケーションキーは、どんなユニークな意味もレゾルバに持たないで、単にキーを要求するアプリケーションの役に立ちます。 サブタイプがアプリケーションキーを特定するのに使用されるならサブタイプを指定するレゾルバの必要性へのインタフェースかアプリケーションのどちらかがすべてのKEY RRsを受け入れて、必要なサブタイプを選ぶことができる必要に注意してください。

   6.  A fault or compromise of a DNS zone key can lead to invalid or
   forged DNS data, but a fault or compromise of an application key
   should have no impact on other DNS data.  Incorrectly adding or
   changing a DNS zone key can invalidate all of the DNS data in the
   zone and in all of its subzones.  By using a compromised key, an

6. DNSゾーンキーの欠点か感染が無効の、または、偽造しているDNSデータにつながることができますが、アプリケーションキーの欠点か感染が他のDNSデータに影響力を全く持つべきではありません。 不当にDNSゾーンキーを加えるか、または変えると、ゾーンと「副-ゾーン」のすべてでDNSデータのすべてを無効にすることができます。 感染しているキーを使用することによって

Massey & Rose               Standards Track                     [Page 4]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[4ページ]RFC3445

   attacker can forge data from the effected zone and for any of its
   sub-zones.  A fault or compromise of an application key has
   implications for that application, but it should not have an impact
   on the DNS.  Note that application key faults and key compromises can
   have an impact on the entire DNS if the application key and DNS zone
   keys are both stored in the KEY RR.

攻撃者は作用しているゾーンとサブゾーンのどれかに関するデータを作り出すことができます。 アプリケーションキーの欠点か感染には、そのアプリケーションのための意味がありますが、それはDNSに影響を与えるべきではありません。 アプリケーションキーとDNSゾーンキーがKEY RRにともに保存されるならアプリケーションキー欠点と主要な感染が全体のDNSに影響を与えることができることに注意してください。

   In summary, DNSSEC keys and application keys differ in most every
   respect.  DNSSEC keys are an essential part of the DNS infrastructure
   and require special handling by DNS administrators and DNS resolvers.
   Application keys are simply another type of data and have no special
   meaning to DNS administrators or resolvers.  These two different
   types of data do not belong in the same resource record.

概要、DNSSECキー、およびアプリケーションキーでは、大部分では、あらゆる敬意が異なります。 DNSSECキーは、DNSインフラストラクチャの不可欠の部分であり、DNS管理者とDNSレゾルバで特別な取り扱いを必要とします。 アプリケーションキーは、単に別のタイプに関するデータであり、DNS管理者かレゾルバにどんな特別な意味も持っていません。 同じリソース記録にはこれらの2つの異なったタイプに関するデータがありません。

3. Definition of the KEY RR

3. 主要なRRの定義

   The KEY RR uses type 25 and is used as resource record for storing
   DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
   octet, the algorithm number octet, and the public key itself.  The
   format is as follows:

KEY RRは、タイプ25を使用して、DNSSECキーを保存するのにリソース記録として使用されます。 KEY RRのためのRDATAは旗、プロトコル八重奏、アルゴリズム数の八重奏、および公開鍵自体から成ります。 形式は以下の通りです:

   ---------------------------------------------------------------------

---------------------------------------------------------------------

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              flags            |   protocol    |   algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                        public key                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| プロトコル| アルゴリズム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | //公開鍵///+++++++++++++++++++++++++++++++++

                             KEY RR Format

主要なRR形式

   ---------------------------------------------------------------------

---------------------------------------------------------------------

   In the flags field, all bits except bit 7 are reserved and MUST be
   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
   are examples of DNSSEC keys that are not zone keys.

旗で、7は、分野、ビット以外のすべてのビット、予約されていて、ゼロであるに違いありません。 Bit7(ゾーン・ビット)が1に用意ができているなら、KEYはDNS Zoneキーです。 Bit7が0に用意ができているなら、KEYはゾーンキーではありません。 SIG(0)/TKEYはゾーンキーでないDNSSECキーに関する例です。

   The protocol field MUST be set to 3.

プロトコル分野を3に設定しなければなりません。

   The algorithm and public key fields are not changed.

アルゴリズムと公開鍵分野は変えられません。

Massey & Rose               Standards Track                     [Page 5]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[5ページ]RFC3445

4. Changes from RFC 2535 KEY RR

4. RFC2535の主要なRRからの変化

   The KEY RDATA format is not changed.

KEY RDATA形式は変えられません。

   All flags except for the zone key flag are eliminated:

ゾーンの主要な旗以外のすべての旗が排除されます:

      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
      and MUST be ignored by the receiver.

A/Cビット(ビット0と1)は排除されます。 それらを0に設定しなければならなくて、受信機で無視しなければなりません。

      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
      and MUST be ignored by the receiver.

旗が噛み付いた広げることは排除されます(ビット3)。 それを0に設定しなければならなくて、受信機で無視しなければなりません。

      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
      MUST be ignored by the receiver.

ホスト/ユーザビット(ビット6)は排除されます。 それを0に設定しなければならなくて、受信機で無視しなければなりません。

      The zone bit (bit 7) remains unchanged.

ゾーン・ビット(ビット7)は変わりがありません。

      The signatory field (bits 12-15) are eliminated by [5].  They MUST
      be set to 0 and MUST be ignored by the receiver.

署名している分野(ビット12-15)は[5]によって排除されます。 それらを0に設定しなければならなくて、受信機で無視しなければなりません。

      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
      set to zero and MUST be ignored by the receiver.

ビット2、4、5、8、9、10、11は変わりがありません。 それらを予約されていて、ゼロに設定しなければならなくて、受信機で無視しなければなりません。

   Assignment of any future KEY RR Flag values requires a standards
   action.

どんな将来のKEY RR Flag値の課題も規格動作を必要とします。

   All Protocol Octet values except DNSSEC (3) are eliminated:

DNSSEC(3)以外のすべてのプロトコルOctet値が排除されます:

      Value 1 (Email) is renamed to RESERVED.

値1(メール)はRESERVEDに改名されます。

      Value 2 (IPSEC) is renamed to RESERVED.

値2(IPSEC)はRESERVEDに改名されます。

      Value 3 (DNSSEC) is unchanged.

値3(DNSSEC)は変わりがありません。

      Value 4 (TLS) is renamed to RESERVED.

値4(TLS)はRESERVEDに改名されます。

      Value 5-254 remains unchanged (reserved).

値5-254は変わりがありません(予約されます)。

      Value 255 (ANY) is renamed to RESERVED.

値255は(少しも)RESERVEDに改名されます。

   The authoritative data for a zone MUST NOT include any KEY records
   with a protocol octet other than 3.  The registry maintained by IANA
   for protocol values is closed for new assignments.

ゾーンのための信頼すべきデータは3以外のプロトコル八重奏があるどんなKEY記録も含んではいけません。 プロトコル値のためにIANAによって維持された登録は新しい課題のために閉じられます。

   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
   RRs with a value other than 3.  If out of date DNS zones contain
   deprecated KEY RRs with a protocol octet value other than 3, then
   simply dropping the deprecated KEY RRs from the KEY RR set would

ネームサーバとレゾルバSHOULDは3以外の値でKEY RRsを含むKEY RRセットを受け入れます。 時代遅れのDNSゾーンが3以外のプロトコル八重奏価値がある推奨しないKEY RRsを含んでいるなら、単にKEY RRからの推奨しないKEY RRsが設定する低下はそうするでしょう。

Massey & Rose               Standards Track                     [Page 6]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[6ページ]RFC3445

   invalidate any associated SIG record(s) and could create caching
   consistency problems.  Note that KEY RRs with a protocol octet value
   other than 3 MUST NOT be used to authenticate DNS data.

どんな関連SIG記録も無効にして、キャッシュしている一貫性問題を生じさせることができました。DNSデータを認証するのに3以外のプロトコル八重奏価値があるKEY RRsを使用してはいけないことに注意してください。

   The algorithm and public key fields are not changed.

アルゴリズムと公開鍵分野は変えられません。

5. Backward Compatibility

5. 後方の互換性

   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
   A properly formatted RFC 2535 zone KEY would have all flag bits,
   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
   Octet set to 3.  This remains true under the restricted KEY.

DNSSECゾーンKEY RRsは変えられないで、後方に残っています。互換性がある。 Zone Bit(ビット7)を除いて、KEYがすべてのフラグビット持っている適切にフォーマットされたRFC2535ゾーンで、0にセットして、プロトコルOctetを3に用意ができさせるでしょう。 これは制限されたKEYの下で本当のままで残っています。

   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
   but the distinction between host and user keys (flag bit 6) is lost.

DNSSEC非ゾーンKEY RRs(SIG(0)/TKEYキー)は後方にそうです。互換性があります、ホストとユーザキー(フラグビット6)の区別だけが無くなっています。

   No backwards compatibility is provided for application keys.  Any
   Email, IPSEC, or TLS keys are now deprecated.  Storing application
   keys in the KEY RR created problems such as keys at the apex and
   large RR sets and some change in the definition and/or usage of the
   KEY RR would have been required even if the approach described here
   were not adopted.

どんな遅れている互換性もアプリケーションキーに提供しません。 どんなメール、IPSEC、またはTLSキーも現在、推奨しないです。 KEY RRにアプリケーションキーを保存すると、頂点のキーや、大きいRRセットや定義におけるいくらかの変化などの問題は生じました、そして、ここで説明されたアプローチが取られなかったとしても、KEY RRの使用法が必要だったでしょう。

   Overall, existing nameservers and resolvers will continue to
   correctly process KEY RRs with a sub-type of DNSSEC keys.

総合的で、既存のネームサーバとレゾルバは、DNSSECキーのサブタイプで正しくKEY RRsを処理し続けるでしょう。

6. Storing Application Keys in the DNS

6. DNSにアプリケーションキーを保存します。

   The scope of this document is strictly limited to the KEY record.
   This document prohibits storing application keys in the KEY record,
   but it does not endorse or restrict the storing application keys in
   other record types.  Other documents can describe how DNS handles
   application keys.

このドキュメントの範囲は厳密にKEY記録に制限されます。 このドキュメントが、KEY記録にアプリケーションキーを保存するのを禁止しますが、それは、他のレコード種類で保存アプリケーションキーを宣伝もしませんし、制限もしません。 他のドキュメントはDNSがどうアプリケーションキーを扱うかを説明できます。

7. IANA Considerations

7. IANA問題

   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
   values 5-254 were made available for assignment by IANA.  This
   document makes two sets of changes to this registry.

RFC2535はDNS KEY RRプロトコルOctet値のためのIANA登録を作成しました。 RFC2535は値1、2、3、4、および255を割り当てました、そして、値5-254をIANAによる課題に利用可能にしました。 このドキュメントはこの登録への2セットの変更を行います。

   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
   remains unchanged as "DNSSEC".

まず最初に、このドキュメントは「予約され」て、Octetが1、2、4、および255を評価するDNS KEY RRプロトコルを再選任します。 DNS Key RRプロトコルOctet Value3は"DNSSEC"として変わりがありません。

Massey & Rose               Standards Track                     [Page 7]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[7ページ]RFC3445

   Second, new values are no longer available for assignment by IANA and
   this document closes the IANA registry for DNS KEY RR Protocol Octet
   Values.  Assignment of any future KEY RR Protocol Octet values
   requires a standards action.

2番目に、新しい値はもうIANAによる課題に利用可能ではありません、そして、このドキュメントはDNS KEY RRプロトコルOctet ValuesのためにIANA登録を閉じます。 どんな将来のKEY RRプロトコルOctet値の課題も規格動作を必要とします。

8. Security Considerations

8. セキュリティ問題

   This document eliminates potential security problems that could arise
   due to the coupling of DNS zone keys and application keys.  Prior to
   the change described in this document, a correctly authenticated KEY
   set could include both application keys and DNSSEC keys.  This
   document restricts the KEY RR to DNS security usage only.  This is an
   attempt to simplify the security model and make it less user-error
   prone.  If one of the application keys is compromised, it could be
   used as a false zone key to create false DNS signatures (SIG
   records).  Resolvers that do not carefully check the KEY sub-type
   could believe these false signatures and incorrectly authenticate DNS
   data.  With this change, application keys cannot appear in an
   authenticated KEY set and this vulnerability is eliminated.

このドキュメントはDNSゾーンキーとアプリケーションキーのカップリングのため起こることができた潜在的警備上の問題を排除します。 本書では説明された変化の前では、正しく認証されたKEYセットはアプリケーションキーとDNSSECキーの両方を含むことができました。 このドキュメントはKEY RRをDNSセキュリティ用法だけに制限します。 これは機密保護モデルを簡素化して、それをより少ないユーザ誤り傾向があるようにする試みです。 アプリケーションキーの1つが感染されるなら、それは誤ったDNS署名(SIG記録)を作成するために主要な誤ったゾーンとして使用されるかもしれません。 丹念にKEYサブタイプをチェックしないレゾルバは、これらが誤った署名であると信じて、不当にDNSデータを認証できました。 この変化で、アプリケーションキーは認証されたKEYセットに現れることができません、そして、この脆弱性は排除されます。

   The format and correct usage of DNSSEC keys is not changed by this
   document and no new security considerations are introduced.

DNSSECキーの形式と正しい使用法はこのドキュメントによって変えられません、そして、どんな新しいセキュリティ問題も紹介されません。

9. Normative References

9. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[2] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

   [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
        2930, September 2000.

[3] イーストレーク、D.、「DNS(TKEY RR)のための秘密鍵設立」、RFC2930、2000年9月。

   [4]  Eastlake, D., "DNS Request and Transaction Signatures
        (SIG(0)s)", RFC 2931, September 2000.

[4] イーストレーク、D.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 2000年9月。

   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
        Update", RFC 3007, November 2000.

[5] ウェリントン、2000年11月、B.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。

Massey & Rose               Standards Track                     [Page 8]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[8ページ]RFC3445

10. Authors' Addresses

10. 作者のアドレス

   Dan Massey
   USC Information Sciences Institute
   3811 N. Fairfax Drive
   Arlington, VA  22203
   USA

ダンマッシーUSC情報科学は3811N.フェアファクス・Driveヴァージニア22203アーリントン(米国)を設けます。

   EMail: masseyd@isi.edu

メール: masseyd@isi.edu

   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-3460
   USA

スコットRoseの規格の国家の研究所と技術100事務局Drive MD20899-3460ゲイザースバーグ(米国)

   EMail: scott.rose@nist.gov

メール: scott.rose@nist.gov

Massey & Rose               Standards Track                     [Page 9]

RFC 3445         Limiting the KEY Resource Record (RR)     December 2002

2002年12月に主要なリソース記録(RR)を制限するマッシーとバラ標準化過程[9ページ]RFC3445

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Massey & Rose               Standards Track                    [Page 10]

マッシーとバラ標準化過程[10ページ]