Internet Engineering Task Force (IETF) R. Reddy
Request for Comments: 6024 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
October 2010
Trust Anchor Management Requirements
Abstract
抽象
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.
トラストアンカーは、公開鍵とそれに関連するデータを介して正式なエンティティを表します。公開鍵は、デジタル署名を検証するために使用され、関連データは、トラストアンカーが権限を持つ情報の種類を制限するために使用されます。証明書利用者は、デジタル署名されたオブジェクトがトラストアンカーの公開鍵を使ってデジタル署名を検証することにより、およびトラストアンカーのために、関連するデータで表現された制約を強制することで有効であるかどうかを判断するために信頼アンカーを使用しています。この文書では、標準のトラストアンカー管理メカニズムの欠如に関連した問題のいくつかを説明し、データ形式と、これらの問題に対処するために設計されたプッシュベースのプロトコルのための要件を定義します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6024.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6024で取得することができます。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Transport Independence . . . . . . . . . . . . . . . . . . 6
3.2. Basic Management Operations . . . . . . . . . . . . . . . 7
3.3. Management Targets . . . . . . . . . . . . . . . . . . . . 7
3.4. Delegation of TA Manager Authority . . . . . . . . . . . . 8
3.5. RFC 5280 Support . . . . . . . . . . . . . . . . . . . . . 9
3.6. Support Purposes other than Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Trust Anchor Format . . . . . . . . . . . . . . . . . . . 10
3.8. Source Authentication . . . . . . . . . . . . . . . . . . 10
3.9. Reduce Reliance on Out-of-Band Trust Mechanisms . . . . . 11
3.10. Replay Detection . . . . . . . . . . . . . . . . . . . . . 11
3.11. Compromise or Disaster Recovery . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . . 13
Digital signatures are used in many applications. For digital signatures to provide integrity and authentication, the public key used to verify the digital signature must be "trusted", i.e., accepted by a relying party (RP) as appropriate for use in the given context. A public key used to verify a signature must be configured as a trust anchor (TA) or contained in a certificate that can be transitively verified by a certification path terminating at a trust anchor. A trust anchor is a public key and associated data used by a relying party to validate a signature on a signed object where the object is either:
デジタル署名は、多くのアプリケーションで使用されています。整合性と認証を提供するために、デジタル署名は、デジタル署名を検証するために使用される公開鍵、すなわち、与えられた文脈での使用に適したように依拠当事者（RP）によって受け入れられ、「信頼できる」ものでなければなりません。署名を検証するために使用される公開鍵は、トラストアンカー（TA）として構成され、または推移トラストアンカーで終端証明経路によって検証することができる証明書に含まれなければなりません。トラストアンカーは、オブジェクトのいずれかである署名付きオブジェクトの署名を検証するために依拠当事者が使用する公開鍵と関連付けられたデータです。
o a public key certificate that begins a certification path terminated by a signature certificate or encryption certificate
O署名証明書または暗号化証明書によって終了証明書パスを開始します公開鍵証明書
o an object, other than a public key certificate or certificate revocation list (CRL), that cannot be validated via use of a certification path
認証パスの使用を介して検証することができない公開鍵証明書または証明書失効リスト（CRL）以外の物体、O
Trust anchors have only local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context in which the RP operates. The associated data defines the scope of a trust anchor by imposing constraints on the signatures that the trust anchor may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types.
トラストアンカーはローカル重要性は、すなわち、各RPは、RPによって、またはRPが動作するコンテキスト内のTAを管理するエンティティのいずれかによって、トラストアンカーのセットで構成されています。関連データは、トラストアンカーを確認するために使用することができるシグネチャに制約を課すことにより、トラストアンカーの範囲を定義します。トラストアンカーがX.509証明書の署名を検証するために使用されている場合、これらの制約は、名前空間、証明書ポリシー、またはアプリケーション/使用タイプの組み合わせを含むことができます。
One use of digital signatures is the verification of signatures on firmware packages loaded into hardware modules, such as cryptographic modules, cable boxes, routers, etc. Since such devices are often managed remotely, the devices must be able to authenticate the source of management interactions and can use trust anchors to perform this authentication. However, trust anchors require management as well. Other applications requiring trust anchor management include web browsers (which use trust anchors when authenticating web servers) and email clients (which use trust anchors when validating signed email and when authenticating recipients of encrypted email).
デジタル署名の1つの用途は、そのようなデバイスはしばしばリモートで管理されているので、デバイス管理相互作用のソースを認証することができなければならない等の暗号モジュール、ケーブルボックス、ルータなど、ハードウェアモジュールにロードされたファームウェアパッケージの署名の検証でありますそして、この認証を実行するためにトラストアンカーを使用することができます。しかし、信頼アンカーは、同様の管理を必要とします。トラストアンカーの管理を必要とする他のアプリケーションは、（Webサーバを認証するときにトラストアンカーを使用する）Webブラウザと（使用信頼アンカーに署名したメールを確認し、暗号化された電子メールの受信者を認証するときに）電子メールクライアントが含まれます。
All applications that rely upon digital signatures rely upon some means of managing one or more sets of trust anchors. Each set of trust anchors is referred to in this document as a trust anchor store. Often, the means of managing trust anchor stores are application-specific and rely upon out-of-band means to establish and maintain trustworthiness. An application may use multiple trust anchor stores, and a given trust anchor store may be used by multiple applications. Each trust anchor store is managed by at least one TA manager; a TA manager may manage multiple TA stores.
デジタル署名に依存しているすべてのアプリケーションは、トラストアンカーの1つ以上のセットを管理するいくつかの手段に依存しています。トラストアンカーの各セットは、トラストアンカーストアとして、この文書で言及されています。多くの場合、トラストアンカーストアを管理する手段は、アプリケーション固有であり、アウトオブバンドに依存して確立し、信頼性を維持することを意味します。アプリケーションは、複数のトラストアンカーストアを使用することができ、所与のトラストアンカーストアは複数のアプリケーションで使用されてもよいです。各トラストアンカーストアは、少なくとも一つのTAマネージャーによって管理されています。 TA管理部は、複数のTAの格納を管理することができます。
The requirements stated in this document were prepared prior to the publication of [RFC5914] and [RFC5934]. The document was not published at that time to allow for changes in requirements during the development of the associated technical specifications. The requirements described below are those that were considered during the development of [RFC5914] and [RFC5934].
この文書に記載されている要件は、[RFC5914]及び[RFC5934]の出版前に調製しました。文書は、関連する技術仕様の開発中に要件の変更を可能にするためにその時点で公表されていませんでした。以下に説明する要件は[RFC5914]及び[RFC5934]の開発中に考慮されたものです。
This section provides an introduction and defines basic terminology. Section 2 describes problems with current trust anchor management methods. Sections 3 and 4 describe requirements and security considerations for a trust anchor management solution.
このセクションでは、導入を提供し、基本的な用語を定義します。第2節では、現在のトラストアンカーの管理方法の問題を説明します。セクション3と4は、トラストアンカー管理ソリューションのための要件とセキュリティの考慮事項について説明します。
The following terms are defined in order to provide a vocabulary for describing requirements for trust anchor management.
次の用語は、トラストアンカーの管理のための要件を記述するための語彙を提供するために定義されています。
Trust Anchor: A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.
トラストアンカー：トラストアンカーは、公開鍵とそれに関連するデータを介して正式なエンティティを表します。公開鍵は、デジタル署名を検証するために使用され、関連データは、トラストアンカーが権限を持つ情報の種類を制限するために使用されます。証明書利用者は、デジタル署名されたオブジェクトがトラストアンカーの公開鍵を使ってデジタル署名を検証することにより、およびトラストアンカーのために、関連するデータで表現された制約を強制することで有効であるかどうかを判断するために信頼アンカーを使用しています。
Trust Anchor Manager: A trust anchor manager is an entity responsible for managing the contents of a trust anchor store. Throughout this document, each trust anchor manager is assumed to be represented as or delegated by a distinct trust anchor.
トラストアンカーマネージャー：トラストアンカーマネージャは、トラストアンカーストアの内容を管理する責任を負うエンティティです。本明細書を通して、各トラストアンカ・マネージャは、次のように表されるか、別個のトラストアンカーによって委任されているものとします。
Trust Anchor Store: A trust anchor store is a set of one or more trust anchors stored in a device. A trust anchor store may be managed by one or more trust anchor managers. A device may have more than one trust anchor store, each of which may be used by one or more applications.
トラストアンカーストア：トラストアンカーストアがデバイスに格納されている1つのまたは複数の信頼アンカーのセットです。トラストアンカーストアは、一つ以上のトラストアンカーマネージャーによって管理されていてもよいです。デバイスは、1つ以上のアプリケーションによって使用されてもよいこれらの各々は、複数のトラストアンカー・ストアを有することができます。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Trust anchors are used to support many application scenarios. Most Internet browsers and email clients use trust anchors when authenticating Transport Layer Security (TLS) sessions, verifying signed email, and generating encrypted email by validating a certification path to a server's certificate, an email originator's certificate, or an email recipient's certificate, respectively. Many software distributions are digitally signed to enable authentication of the software source prior to installation. Trust anchors that support these applications are typically installed as part of the operating system (OS) or application, installed using an enterprise configuration management system, or installed directly by an OS or application user.
トラストアンカーは、多くのアプリケーションシナリオをサポートするために使用されています。 、トランスポート層セキュリティ（TLS）セッションを認証する署名したメールを確認し、それぞれのサーバの証明書、電子メールの発信元の証明書、または電子メールの受信者の証明書への証明書パスを検証することにより、暗号化された電子メールを生成するときにほとんどのインターネットブラウザや電子メールクライアントは、信頼アンカーを使用します。多くのソフトウェアのディストリビューションは、デジタルインストール前に、ソフトウェアのソースの認証を可能にするために署名されています。これらのアプリケーションをサポートするトラストアンカーは、典型的には、オペレーティング・システムの一部（OS）やアプリケーションとしてインストールエンタープライズ構成管理システムを使用してインストール、またはOSやアプリケーションユーザによって直接インストールされています。
Trust anchors are typically stored in application-specific or OS-specific trust anchor stores. Often, a single machine may have a number of different trust anchor stores that may not be synchronized. Reviewing the contents of a particular trust anchor store typically involves use of a proprietary tool that interacts with a particular type of trust store.
トラストアンカーは通常、アプリケーション固有またはOS固有のトラストアンカーストアに格納されています。多くの場合、単一のマシンが同期されないことが異なるトラストアンカーの店舗数を有することができます。特定のトラストアンカーストアの内容を確認することは一般的に信頼ストアの特定のタイプと相互作用し、独自のツールの使用を含みます。
The presence of a trust anchor in a particular store often conveys implicit authorization to validate signatures for any contexts from which the store is accessed. For example, the public key of a timestamp authority (TSA) may be installed in a trust anchor store to validate signatures on timestamps [RFC3161]. However, if the store containing this TA is used by multiple applications that serve different purposes, the same key may be used (inappropriately) to validate other types of objects such as certificates or Online Certificate Status Protocol (OCSP) responses. Prior to publication of [RFC5914], there was no standard general-purpose mechanism for limiting the applicability (scope) of a trust anchor. A common practice to address this problem is to place different TAs in different stores and limit the set of applications that access a given TA store.
特定の店舗でのトラストアンカーの存在は、多くの場合、ストアがアクセスされたすべてのコンテキストのための署名を検証するために、暗黙の承認を伝えます。例えば、タイムスタンプ局（TSA）の公開鍵は、タイムスタンプ、[RFC3161]の署名を検証するためにトラストアンカーストアにインストールされてもよいです。このTAを含むストアが異なる目的を果たす複数のアプリケーションで使用されている場合は、同じキーは、証明書やオンライン証明書状態プロトコル（OCSP）応答など他のタイプのオブジェクトを検証する（不適切な）を使用することができます。 [RFC5914]の出版に先立ち、トラストアンカーの適用性（範囲）を制限するための標準的な汎用メカニズムは存在しませんでした。この問題に対処するのが一般的には、異なる店舗で異なるのTAを配置し、与えられたTAストアにアクセスするアプリケーションのセットを制限することです。
Trust relationships between Public Key Infrastructures (PKIs) are negotiated by policy authorities. Negotiations frequently require significant time to ensure all participating parties' requirements are satisfied. These requirements are expressed, to some extent, in public key certificates via policy constraints, name constraints, etc. In order for these requirements to be enforced, trust anchor stores must be managed in accord with policy authority intentions. Otherwise, the constraints defined in a cross-certificate could be circumvented by recognizing the subject of the cross certificate as a trust anchor, which would enable path processing implementations to avoid the cross-certificate.
公開キー基盤（PKIの）間の信頼関係は、政策当局によって交渉されています。交渉は頻繁に参加するすべての当事者の要件が満たされていることを確認するためにかなりの時間を必要とします。これらの要件が適用されるため、これらの要件は、トラストアンカー店は政策当局の意図と一致して管理する必要があり、ためになどポリシー制約、名前制約を介して公開鍵証明書には、ある程度、表現されています。そうでない場合は、クロス証明書に定義された制約は、相互認証を回避するために、パス処理の実装を可能にするトラストアンカーとしてのクロス証明書のサブジェクトを認識することによって回避することができます。
Trust anchors are often represented as self-signed certificates, which provide no useful means of establishing the validity of the information contained in the certificate. Confidence in the integrity of a trust anchor is typically established through out-of-band means, often by checking the "fingerprint" (one-way hash) of the self-signed certificate with an authoritative source. Routine trust anchor rekey operations typically require similar out-of-band checks, though in-band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) [RFC4210]. Ideally, only the initial set of trust anchors are installed in a particular trust anchor store should require out-of-band verification, particularly when the costs of performing out-of-band checks commensurate with the security requirements of applications using the trust anchor store are high.
トラストアンカーは、多くの場合、証明書に含まれている情報の有効性を確立する有用な手段を提供していない自己署名証明書として表現されています。トラストアンカーの整合性への信頼は、一般的に、多くの場合、信頼できるソースで自己署名証明書の「指紋」（一方向ハッシュ）をチェックすることにより、アウトオブバンド手段を介して確立されます。トラストアンカーのインバンドリキー証明書管理プロトコル（CMP）[RFC4210]でサポートされていても日常のトラストアンカーの再入力操作は、通常、同様のアウトオブバンドのチェックが必要です。理想的には、トラストアンカーの唯一の最初のセットは、アウトオブバンドの検証を必要とすべき特定のトラストアンカーストアにインストールされている場合は特にトラストアンカーストアを使用するアプリケーションのセキュリティ要件に見合ったアウトオブバンドのチェックを実行するコスト高いです。
Despite the prevalent use of trust anchors, there is neither a standard means for discovering the set of trust anchors installed in a particular trust anchor store nor a standard means of managing those trust anchors. The remainder of this document describes requirements for a solution to this problem along with some security considerations.
トラストアンカーの普及使用しているにもかかわらず、信頼特定のトラストアンカーの店舗に設置されたアンカーでも、これらのトラストアンカーを管理する標準的な手段のセットを発見するための標準的な手段でもないがあります。このドキュメントの残りの部分は、いくつかのセキュリティ上の考慮事項に加えて、この問題を解決するための要件について説明します。
This section describes the requirements for a trust anchor management protocol. Requirements are provided for trust anchor contents as well as for trust anchor store management operations.
このセクションでは、トラストアンカーの管理プロトコルのための要件について説明します。要件は、トラストアンカーの内容のためだけでなく、トラストアンカーストアの管理操作のために提供されます。
A general-purpose solution for the management of trust anchors MUST be transport independent in order to apply to a range of device communications environments. It MUST work in both session-oriented and store-and-forward communications environments as well as in both push and pull distribution models. To accommodate both communication models in a uniform fashion, connectionless integrity and data origin authentication for TA transactions MUST be provided at the application layer. Confidentiality MAY be provided for such transactions.
トラストアンカーの管理のための汎用ソリューションは、デバイス通信環境の範囲に適用するために、トランスポート独立していなければなりません。これは、両方のセッション指向およびストアアンドフォワード通信環境ならびに両方のプッシュで作業し、流通モデルを引く必要があります。均一な様式で両方の通信モデルに対応するために、TAトランザクションのコネクションレス完全性とデータ発信元認証は、アプリケーション層に提供しなければなりません。守秘義務は、そのような取引のために提供することができます。
Not all devices that use trust anchors are available for online management operations; some devices may require manual interaction for trust anchor management. Data origin authentication and integrity are required to ensure that the transaction has not been modified en route. Only connectionless integrity is required, for compatibility with store-and-forward contexts.
信頼アンカーを使用しないすべてのデバイスがオンラインの管理操作が可能です。一部のデバイスは、トラストアンカーの管理のためのマニュアルの対話が必要な場合があります。データ発信元認証と完全性は、トランザクションが途中で変更されていないことを保証するために必要とされています。唯一のコネクションレスインテグリティはストアアンドフォワードコンテキストとの互換性のために、必要とされます。
At a minimum, a protocol used for trust anchor management MUST enable a trust anchor manager to perform the following operations:
最低でも、トラストアンカーの管理に使用されるプロトコルは、以下の操作を実行するトラストアンカー・マネージャーを有効にする必要があります。
o Determine which trust anchors are installed in a particular trust anchor store
O特定のトラストアンカーストアにインストールされている信頼のアンカーを決定
o Add one or more trust anchors to a trust anchor store
Oトラストアンカーストアへの1つ以上の信頼アンカーを追加します。
o Remove one or more trust anchors from a trust anchor store
Oトラストアンカーストアから1つまたは複数の信頼アンカーを削除します
o Replace an entire trust anchor store
O全体トラストアンカーストアを交換してください
A trust anchor management protocol MUST provide support for these basic operations; however, not all implementations must support each option. For example, some implementations may support only replacement of trust anchor stores.
トラストアンカーの管理プロトコルは、これらの基本的な操作のサポートを提供しなければなりません。ただし、すべての実装は、各オプションをサポートしている必要があります。例えば、いくつかの実装は、トラストアンカー店の唯一の交換をサポートすることができます。
These requirements describe the core operations required to manage the contents of a trust anchor store. An edit operation was omitted for the sake of simplicity, with consecutive remove and add operations used for this purpose. A single add or remove operation can act upon more than one trust anchor to avoid unnecessary round trips and are provided to avoid the need to always replace an entire trust anchor store. Trust anchor store replacement may be useful as a simple, higher-bandwidth alternative to add and remove operations.
これらの要件は、トラストアンカーストアの内容を管理するために必要なコア動作を示します。編集操作は、連続した削除して、簡略化のために省略して、この目的のために使用する操作を追加しました。単一追加または削除操作が不要なラウンドトリップを回避するために、複数のトラストアンカーに作用することができ、常に全体のトラストアンカーストアを交換する必要性を回避するために設けられています。トラストアンカーストアの交換は操作を追加し、削除するための簡単な、高帯域幅の代替として有用である可能性があります。
A protocol for TA management MUST allow a TA management transaction to be directed to:
TA管理のためのプロトコルは、TA管理トランザクションはに導くことを許容しなければなりません。
All TA stores for which the manager is responsible
管理者が担当するすべてのTAの店
An enumerated list of one or more named groups of trust anchor stores
トラストアンカー店の一つ以上の名前付きグループの列挙リスト
An individual trust anchor store
個別のトラストアンカーストア
Connections between PKIs can be accomplished using different means. Unilateral or bilateral cross-certification can be performed, or a community may simply elect to explicitly accept a trust anchor from another community. Typically, these decisions occur at the enterprise level. In some scenarios, it can be useful to establish these connections for a small community within an enterprise. Enterprise-wide mechanisms such as cross-certificates are ill-suited for this purpose since certificate revocation or expiration affects the entire enterprise.
PKI間の接続は、様々な手段を用いて達成することができます。片側または両側の相互認証を行うことができ、またはコミュニティは、単に明示的に他のコミュニティからのトラストアンカーを受け入れることを選択するかもしれません。典型的には、これらの決定は、企業レベルで起こります。いくつかのシナリオでは、企業内の小さなコミュニティのためにこれらの接続を確立するのに役立ちます。証明書失効又は有効期限が企業全体に影響を与えるので、このような相互認証などの企業規模の機構は、この目的のために病気に適しています。
A trust anchor management protocol can address this issue by supporting limited installation of trust anchors (i.e., installation of TAs in subsets of the enterprise user community), and by supporting expression of constraints on trust anchor use by relying parties. Limited installation requires the ability to identify the members of the community that are intended to rely upon a particular trust anchor, as well as the ability to query and report on the contents of trust anchor stores. Trust anchor constraints can be used to represent the limitations that might otherwise be expressed in a cross-certificate, and limited installation ensures the recognition of the trust anchor does not necessarily encompass an entire enterprise.
トラストアンカー管理プロトコル（すなわち、エンタープライズ・ユーザー・コミュニティのサブセットにおけるTAの設置）、および依拠当事者によってトラストアンカーの使用上の制約の表現をサポートすることにより、トラストアンカーの限られた設置をサポートすることにより、この問題に対処することができます。限られた設置は、特定のトラストアンカーと同様に照会し、トラストアンカーストアの内容を報告する能力に依存するように意図されているコミュニティのメンバーを特定する能力が必要です。トラストアンカーの制約は、そうでなければ相互認証において発現されるかもしれない制限を表すために使用することができ、限られた設置は、必ずしも企業全体を包含しないトラストアンカーの認識を確実にします。
Trust anchor configurations may be uniform across an enterprise, or they may be unique to a single application or small set of applications. Many devices and some applications utilize multiple trust anchor stores. By providing means of addressing a specific store or collections of stores, a trust anchor management protocol can enable efficient management of all stores under a trust anchor manager's control.
トラストアンカー構成は、企業全体に均一であってもよいし、またはそれらは、単一のアプリケーションまたはアプリケーションの小さなセットに固有であってもよいです。多くのデバイスといくつかのアプリケーションでは、複数のトラストアンカーストアを利用しています。特定の店舗や店舗のコレクションに対処する手段を提供することにより、信頼アンカーの管理プロトコルは、トラストアンカーマネージャの制御下にあるすべての店舗の効率的な管理を可能にすることができます。
A trust anchor management protocol MUST enable secure transfer of control of a trust anchor store from one trust anchor manager to another. It also SHOULD enable delegation for specific operations without requiring delegation of the overall trust anchor management capability itself.
トラストアンカー管理プロトコルは、別のトラストアンカーマネージャからトラストアンカーストアの制御の安全な転送を有効にする必要があります。また、全体的なトラストアンカー管理機能自体の委任を必要とせずに、特定の操作のための委任を有効にする必要があります。
Trust anchor manager rekey is one type of transfer that must be supported. In this case, the new key will be assigned the same privileges as the old key.
トラストアンカーマネージャの再入力をサポートしなければならない転送の一種です。この場合は、新しいキーは古いキーと同じ権限が割り当てられます。
Creation of trust anchors for specific purposes, such as firmware signing, is another example of delegation. For example, a trust anchor manager may delegate only the authority to sign firmware to an entity, but disallow further delegation of that privilege, or the trust anchor manager may allow its delegate to further delegate firmware signing authority to other entities.
そのようなファームウェアの署名など、特定の目的のために、トラストアンカーの作成は、代表団の別の例です。例えば、トラストアンカーマネージャは、そのデリゲートは、さらに他のエンティティへのファームウェアの署名権限を委任することを可能にするエンティティにファームウェアを署名したが、さらにその権限の委譲、またはトラストアンカーマネージャを禁止するだけの権限を委任することができます。
A trust anchor management protocol MUST enable management of trust anchors that will be used to validate certification paths and CRLs in accordance with [RFC5280] and [RFC5055]. A trust anchor format MUST enable the representation of constraints that influence certification path validation or otherwise establish the scope of usage of the trust anchor public key. Examples of such constraints are name constraints, certificate policies, and key usage.
トラストアンカー管理プロトコルは[RFC5280]及び[RFC5055]に従って証明経路とCRLを検証するために使用されるトラストアンカーの管理を有効にする必要があります。トラストアンカーの形式は、認証パス検証に影響を与えるか、そうでない場合は、トラストアンカーの公開鍵の使用の範囲を確立する制約の表現を有効にする必要があります。そのような制約の例としては、名前制約、証明書ポリシー、およびキー使用されています。
Certification path validation is one of the most common applications of trust anchors. The rules for using trust anchors for path validation are established in [RFC5280]. [RFC5055] describes the use of trust anchors for delegated path validation. Trust anchors used to validate certification paths are responsible for providing, possibly through a delegate, the revocation status information of certificates it issues; this is often accomplished by signing a CRL.
認証パス検証は、トラストアンカーの最も一般的なアプリケーションの一つです。パス検証の信頼アンカーを使用するための規則は、[RFC5280]で確立されています。 [RFC5055]は委任パス検証のためのトラストアンカーの使用を記載しています。証明書パスの検証に使用されるトラストアンカーは、おそらくデリゲートを通じて、それが発行する証明書の失効ステータス情報を提供する責任があります。これは、多くの場合、CRLに署名することによって達成されます。
A trust anchor management protocol MUST enable management of trust anchors that can be used for purposes other than certification path validation, including trust anchors that cannot be used for certification path validation. It SHOULD be possible to authorize a trust anchor to delegate authority (to other TAs or certificate holders) and to prevent a trust anchor from delegating authority.
トラストアンカー管理プロトコルは、認証パスの検証のために使用することができないトラストアンカーを含む認証パスの検証以外の目的に使用することができるトラストアンカーの管理を有効にする必要があります。 （他のTAまたは証明書保有者への）権限を委任すると権限を委譲からトラストアンカーを防ぐために、トラストアンカーを承認することができるはずです。
Trust anchors are used to validate a variety of signed objects, not just public key certificates and CRLs. For example, a trust anchor may be used to verify firmware packages [RFC4108], OCSP responses [RFC2560], Server-Based Certificate Validation Protocol (SCVP) responses [RFC5055], or timestamps [RFC3161]. TAs that are authorized for use with some or all of these other types of operations may not be authorized to verify public key certificates or CRLs. Thus, it is important to be able to impose constraints on the ways in which a given TA is employed.
トラストアンカーは、署名されたオブジェクトだけではなく、公開鍵証明書とCRLの多様性を検証するために使用されています。例えば、トラストアンカーは、ファームウェアパッケージ[RFC4108]、OCSPレスポンス[RFC2560]、サーバーベースの証明書の検証プロトコル（SCVP）応答[RFC5055]、またはタイムスタンプ[RFC3161]を確認するために使用することができます。これらの操作の他のタイプのいくつかまたは全てで使用するために認可されているTAは、公開鍵証明書やCRLを検証することを許可することはできません。したがって、所与のTAが使用される方法に制約を課すことができることが重要です。
Minimally, a trust anchor management protocol MUST support management of trust anchors represented as self-signed certificates and trust anchors represented as a distinguished name, public key information, and, optionally, associated data. The definition of a trust anchor MUST include a public key, a public key algorithm, and, if necessary, public key parameters. When the public key is used to validate certification paths or CRLs, a distinguished name also MUST be included per [RFC5280]. A trust anchor format SHOULD enable specification of a public key identifier to enable other applications of the trust anchor, for example, verification of data signed using the Cryptographic Message Syntax (CMS) SignedData structure [RFC5652]. A trust anchor format also SHOULD enable the representation of constraints that can be applied to restrict the use of a trust anchor.
最小限、トラストアンカー管理プロトコル識別名、公開鍵情報、及び、必要に応じて、関連するデータとして表される自己署名証明書およびトラストアンカーとして表さトラストアンカーの管理をサポートしなければなりません。トラストアンカーの定義は、公開鍵、公開鍵アルゴリズム、および、必要に応じて、公開鍵のパラメータを含まなければなりません。公開鍵は、証明書パスまたはCRLを検証するために使用される場合、識別名はまた、[RFC5280]あたりに含まなければなりません。トラストアンカーフォーマットがトラストアンカーの他のアプリケーションを可能にするために、公開鍵識別子の指定を有効にする必要があり、例えば、データの検証は、暗号メッセージ構文（CMS）のSignedData構造[RFC5652]を使用して署名しました。トラストアンカーのフォーマットは、トラストアンカーの使用を制限するために適用できる制約の表現を有効にする必要があります。
Prior to the publication of [RFC5914], there was no standardized format for trust anchors. Self-signed X.509 certificates are typically used, but [RFC5280] does not mandate a particular trust anchor representation. It requires only that a trust anchor's public key information and distinguished name be available during certification path validation. CMS is widely used to protect a variety of types of content using digital signatures, including contents that may be verified directly using a trust anchor, such as firmware packages [RFC4108]. Constraints may include a validity period, constraints on certification path validation, etc.
[RFC5914]の出版に先立ち、トラストアンカーのための標準フォーマットが存在しませんでした。自己署名X.509証明書は、一般的に使用されますが、[RFC5280]は、特定のトラストアンカー表現を強制しません。これは、トラストアンカーの公開鍵情報と識別名が証明書パス検証時に利用できるようにすることだけです。 CMSは、広くそのようなファームウェアパッケージ[RFC4108]などのトラストアンカーを使用して直接確認することができるコンテンツを含むデジタル署名を使用して、コンテンツのさまざまな種類のを保護するために使用されます。制約有効期間を含むことができ、証明書パス検証の制約など
An entity receiving trust anchor management data MUST be able to authenticate the identity of the party providing the information and MUST be able to confirm the party is authorized to provide that trust anchor information.
トラストアンカーの管理データを受信エンティティは、情報を提供する当事者の身元を認証できなければならないし、そのトラストアンカー情報を提供するために許可されているパーティーを確認できなければなりません。
A trust anchor manager MUST be able to authenticate which trust anchor store corresponds to a report listing the contents of the trust anchor store and be able to confirm the contents of the report have not been subsequently altered.
トラストアンカーマネージャは、トラストアンカーストアの内容をリストレポートに対応するトラストアンカーストア認証し、報告書の内容が、その後変更されていない確認することができることができなければなりません。
Data origin authentication and integrity are required to support remote management operations, even when TA management transactions are effected via store-and-forward communications.
データ発信元認証と完全性をTA管理トランザクションがストアアンドフォワード通信を介して行われた場合でも、リモート管理操作をサポートするために必要とされます。
When performing add operations, a trust anchor management protocol SHOULD enable TA integrity to be checked automatically by a relying party without relying on out-of-band trust mechanisms.
操作を追加実行するときに、トラストアンカーの管理プロトコルは、帯域外信託の仕組みに頼ることなく、依拠当事者によって自動的にチェックされるTAの整合性を有効にする必要があります。
Traditionally, a trust anchor is distributed out-of-band with its integrity checked manually prior to installation. Installation typically is performed by anyone with sufficient administrative privilege on the system receiving the trust anchor. Reliance on out-of-band trust mechanisms is one problem with current trust anchor management approaches, and reduction of the need to use out-of-band trust mechanisms is a primary motivation for developing a trust anchor management protocol. Ideally, out-of-band trust mechanisms will be required only during trust anchor store initialization.
伝統的に、トラストアンカーは、インストール前に手動で確認し、その完全にアウト・オブ・バンド配布されています。インストールは通常、トラストアンカーを受けるシステム上で十分な管理者権限を持つ誰もが実行されます。アウトオブバンドの信頼メカニズムへの依存度は現在のトラストアンカー管理手法の一つの問題である、とアウトオブバンドの信頼メカニズムを使用する必要性の低下は、トラストアンカーの管理プロトコルを開発するための主な動機です。理想的には、アウトオブバンドの信頼メカニズムは、信頼アンカーストアの初期化の際に必要となります。
A trust anchor management protocol MUST enable participants engaged in a trust anchor management protocol exchange to detect replay attacks. A replay detection mechanism that does not introduce a requirement for a reliable source of time MUST be available. Mechanisms that do require a reliable source of time MAY be available.
トラストアンカーの管理プロトコルは、リプレイ攻撃を検出するために、トラストアンカー管理プロトコル交換に従事する参加者を有効にする必要があります。時間の信頼できるソースの要件を導入しないリプレイ検出メカニズムが使用可能でなければなりません。時間の信頼できる情報源を必要としますメカニズムが利用可能であってもよいです。
Detection of replays of trust anchor management transactions is required to support remote management operations. Replay of old trust anchor management transactions could result in the reintroduction of compromised trust anchors to a trust anchor store, potentially exposing applications to malicious signed objects or certification paths.
トラストアンカー管理トランザクションのリプレイの検出は、リモート管理操作をサポートするために必要です。古いトラストアンカー管理トランザクションのリプレイは、潜在的に悪質な署名オブジェクトまたは証明書パスにアプリケーションをさらす、トラストアンカーストアに妥協トラストアンカーの再導入につながる可能性があります。
Some devices that utilize trust anchors have no access to a reliable source of time, so a replay detection mechanism that requires a reliable time source is insufficient.
トラストアンカーを利用いくつかのデバイスは、時間の信頼できる情報源にアクセスできませんので、信頼できる時刻源が必要ですリプレイ検出メカニズムが不十分です。
A trust anchor management protocol MUST enable recovery from the compromise or loss of a trust anchor private key, including the private key authorized to serve as a trust anchor manager, without requiring re-initialization of the trust store.
トラストアンカーの管理プロトコルは、信頼ストアの再初期化を必要とせずに、トラストアンカーマネージャとして機能する権限秘密鍵を含むトラストアンカー秘密鍵の妥協や損失からの回復を有効にする必要があります。
Compromise or loss of a private key corresponding to a trust anchor can have significant negative consequences. Currently, in some cases, re-initialization of all affected trust anchor stores is required to recover from a lost or compromised trust anchor key. Due to the costs associated with re-initialization, a trust anchor management protocol should support recovery options that do not require trust anchor store re-initialization.
トラストアンカーに対応する秘密鍵の危殆または損失は有意な負の影響を持つことができます。現在、いくつかのケースでは、影響を受けるすべてのトラストアンカー店の再初期化は、紛失または妥協トラストアンカーキーから回復するために必要とされます。再初期化に関連するコストに、トラストアンカーの管理プロトコルは、トラストアンカーストア再初期化を必要としないリカバリー・オプションをサポートする必要があります。
The public key used to authenticate a TA management transaction may have been placed in the client as the result of an earlier TA management transaction or during an initial bootstrap configuration operation. In most scenarios, at least one public key authorized for trust anchor management must be placed in each trust anchor store to be managed during the initial configuration of the trust anchor store. This public key may be transported and checked using out-of-band means. In all scenarios, regardless of the authentication mechanism, at least one trust anchor manager must be established for each trust anchor store during the initial configuration of the trust anchor store.
TA管理トランザクションを認証するために使用される公開鍵は、以前のTA管理トランザクションの結果として、または初期ブートストラップコンフィギュレーション操作中に、クライアントに置かれている場合があります。ほとんどのシナリオでは、トラストアンカーの管理のために認可少なくとも一つの公開鍵は、トラストアンカーストアの初期設定時に管理できるように、各トラストアンカーストアに配置する必要があります。この公開鍵は、輸送およびアウトオブバンド手段を用いて確認することができます。すべてのシナリオでは、関係なく、認証メカニズムの、少なくとも一つのトラストアンカー・マネージャは、トラストアンカーストアの初期構成時に各トラストアンカーストアのために確立されなければなりません。
Compromise of a trust anchor's private key can result in many security problems including issuance of bogus certificates or installation of rogue trust anchors.
トラストアンカーの秘密鍵の危殆は、偽の証明書や不正な信頼アンカーの設置の発行など、多くのセキュリティ上の問題をもたらす可能性があります。
Usage of trust anchor-based constraints requires great care when defining trust anchors. Errors on the part of a trust anchor manager could result in denial of service or have serious security consequences. For example, if a name constraint for a trust anchor that serves as the root of a PKI includes a typo, denial of service results for certificate holders and relying parties. If a trust anchor manager inadvertently delegates all of its privileges and the delegate subsequently removes the trust anchor manager from trust anchor stores now under its control, recovery may require re-initialization of all effected trust anchor stores.
トラストアンカーを定義するときに、トラストアンカーベースの制約の使用は細心の注意が必要です。トラストアンカーマネージャの一部のエラーは、サービス拒否が発生するまたは重大なセキュリティ上の影響を与える可能性があります。例えば、PKIのルートとして機能トラストアンカーの名前制約はタイプミス、証明書保有者と信頼者のためのサービスの結果の拒否が含まれている場合。トラストアンカーマネージャ不注意代表者にその権限の全てと、デリゲートは、その後、今その制御下トラストアンカーストアからトラストアンカーマネージャを削除するには、回復はすべての影響をトラストアンカー店の再初期化が必要な場合があります。
RFC 5280 requires that certificate path validation be initialized with a TA subject name and public key, but does not require processing of other information, such as name constraints extensions. Inclusion of constraints in trust anchors is optional. When constraints are explicitly included by a trust anchor manager using a trust anchor management protocol, there exists an expectation that the certificate path validation algorithm will make use of the constraints. Application owners must confirm the path processing implementations support the processing of TA-based constraints, where required.
RFC 5280には、このような名前制約の拡張機能として、証明書パス検証がTAのサブジェクト名と公開鍵で初期化されている必要がありますが、他の情報の処理を必要としません。トラストアンカー内の制約を含めることは任意です。制約を明示的にトラストアンカーの管理プロトコルを使用したトラストアンカーマネージャーによって含まれている場合は、証明書パス検証アルゴリズムは、制約を利用するという予想があります。アプリケーション所有者は、処理の実装が必要なTAベース制約の処理をサポートするパスを確認しなければなりません。
Many of the security considerations from [RFC5280] are also applicable to trust anchor management.
[RFC5280]からのセキュリティの考慮事項の多くは、アンカーの管理を信頼するために適用可能です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]フリーマン、T.、Housley氏、R.、Malpani、A.、クーパー、D.、およびW.ポーク、 "サーバーベースの証明書の検証プロトコル（SCVP）"、RFC 5055、2007年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161]アダムス、C.、カイン、P.、ピンカス、D.、およびR. Zuccherato、 "インターネットX.509公開鍵インフラストラクチャのタイムスタンププロトコル（TSP）"、RFC 3161、2001年8月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108] Housley氏、R.、 "ファームウェアパッケージを保護するために暗号メッセージ構文（CMS）の使用"、RFC 4108、2005年8月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210]アダムス、C.、ファレル、S.、Kause、T.、およびT. Mononen、 "インターネットX.509公開鍵基盤証明書管理プロトコル（CMP）"、RFC 4210、2005年9月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley氏、R.、 "暗号メッセージ構文（CMS）"、STD 70、RFC 5652、2009年9月。
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010.
[RFC5914] Housley氏、R.、アシュモア、S.、およびC.ウォレス、 "トラストアンカーフォーマット"、RFC 5914、2010年6月。
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010.
[RFC5934] Housley氏、R.、アシュモア、S.、およびC.ウォレス、 "トラストアンカー管理プロトコル（TAMP）"、RFC 5934、2010年8月。
Authors' Addresses
著者のアドレス
Raksha Reddy National Security Agency Suite 6599 9800 Savage Road Fort Meade, MD 20755
Rakshaレディ国家安全保障局（NSA）のスイート6599 9800サベージ道路フォートミード、MD 20755
EMail: r.reddy@radium.ncsc.mil
メールアドレス：r.reddy@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102
カール・ウォレスCygnacomソリューションスイート5400 7925ジョーンズ支店ドライブマクリーン、VA 22102
EMail: cwallace@cygnacom.com
メールアドレス：cwallace@cygnacom.com