[要約] RFC 6024は、信頼アンカーの管理要件に関するガイドラインであり、信頼アンカーの設定、更新、削除、および監視に関する手順を提供します。その目的は、信頼アンカーの効果的な管理を通じて、セキュリティポリシーの適用と信頼性の確保を支援することです。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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:
デジタル署名は、多くのアプリケーションで使用されています。デジタル署名が整合性と認証を提供するためには、デジタル署名の検証に使用される公開鍵は、「信頼されている」必要があります。署名を確認するために使用される公開鍵は、信頼アンカー（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
o 公開キー証明書または証明書取消リスト（CRL）以外のオブジェクトは、認証パスの使用によって検証できません
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が動作するコンテキストでTASを管理するエンティティによって、信頼アンカーのセットで構成されます。関連データは、信頼アンカーが検証するために使用される可能性のある署名に制約を課すことにより、信頼アンカーの範囲を定義します。たとえば、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サーバーを認証するときにトラストアンカーを使用）および電子メールクライアント（署名付きメールを検証するとき、および暗号化された電子メールの受信者を認証するときにTrust Anchorsを使用）が含まれます。
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つ以上の信頼アンカーを管理する何らかの手段に依存しています。このドキュメントでは、信頼のアンカーの各セットが信頼のアンカーストアと呼ばれます。多くの場合、信頼できるアンカーストアを管理する手段はアプリケーション固有であり、信頼性を確立および維持するために帯域外の手段に依存しています。アプリケーションは複数のトラストアンカーストアを使用する場合があり、特定のトラストアンカーストアを複数のアプリケーションで使用できます。各トラストアンカーストアは、少なくとも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 Managerは、Trust Anchor Storeのコンテンツを管理する責任を負うエンティティです。このドキュメント全体で、各トラストアンカーマネージャーは、明確な信頼アンカーとして表されるか、委任されていると想定されています。
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つ以上の信頼できるアンカーマネージャーによって管理される場合があります。デバイスには複数のトラストアンカーストアがあり、それぞれが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
信頼できるアンカーストアの1つ以上の名前付きグループの列挙リスト
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.
Trust Anchor Management Protocolは、信頼アンカーの限られたインストール（つまり、エンタープライズユーザーコミュニティのサブセットに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 Management Protocolは、あるTrust Anchor Managerから別のTrust Anchor Managerへのトラストアンカーストアの制御の安全な転送を可能にする必要があります。また、全体的なトラストアンカー管理機能自体を委任することなく、特定の操作の委任を可能にするはずです。
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.
Trust Anchor Manager Rekeyは、サポートする必要がある1つのタイプの転送です。この場合、新しいキーには古いキーと同じ特権が割り当てられます。
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.
ファームウェアの署名など、特定の目的のための信頼アンカーの作成は、委任のもう1つの例です。たとえば、トラストアンカーマネージャーは、ファームウェアにエンティティに署名する権限のみを委任することができますが、その特権のさらなる委任を禁止するか、トラストアンカーマネージャーが他のエンティティにファームウェア署名権限をさらに委任できるようにすることができます。
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]に従って認証パスとCRLSを検証するために使用される信頼アンカーの管理を可能にする必要があります。トラストアンカー形式は、認証パスの検証に影響を与える制約の表現を可能にする必要があります。そうしないと、信頼アンカー公開キーの使用範囲を確立する必要があります。このような制約の例は、名前の制約、証明書ポリシー、および主要な使用法です。
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.
認定パス検証は、信頼のアンカーの最も一般的なアプリケーションの1つです。パス検証に信頼アンカーを使用するためのルールは、[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]を検証することができます。これらの他のタイプのオペレーションの一部またはすべてで使用が許可されているTASは、公開キー証明書または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.
Trust Anchor Managerは、Trust Anchor StoreがTrust Anchor Storeの内容をリストするレポートに対応し、レポートの内容がその後変更されていないことを確認できることを認証できる必要があります。
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.
ADD操作を実行する場合、Trust Anchor Management Protocolは、帯域外の信頼メカニズムに依存することなく、依存関係者によって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.
従来、信頼のアンカーは、インストール前に手動でその完全性をチェックして、帯域外で配布されています。通常、インストールは、トラストアンカーを受け取るシステムに十分な管理特権を持つ人によって実行されます。帯域外の信頼メカニズムへの依存は、現在の信頼アンカー管理アプローチの1つの問題であり、帯域外の信頼メカニズムを使用する必要性の削減は、信頼アンカー管理プロトコルを開発するための主要な動機です。理想的には、帯域外の信頼メカニズムは、トラストアンカーストアの初期化中にのみ必要です。
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管理トランザクションの結果として、または最初のブートストラップ構成操作の結果としてクライアントに配置されている可能性があります。ほとんどのシナリオでは、トラストアンカーストアの最初の構成中に管理される各トラストアンカーストアに信頼アンカー管理を許可された少なくとも1つの公開キーを配置する必要があります。この公開鍵は、輸送され、帯域外の手段を使用してチェックされる場合があります。すべてのシナリオで、認証メカニズムに関係なく、信頼アンカーストアの初期構成中に、各トラストアンカーストアに対して少なくとも1つの信頼アンカーマネージャーを確立する必要があります。
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の件名名と公開キーで初期化する必要がありますが、名前の制約拡張などの他の情報の処理は必要ありません。トラストアンカーに制約を含めることはオプションです。Trust Anchor Management Protocolを使用してTrust Anchor Managerによって制約が明示的に含まれる場合、証明書パス検証アルゴリズムが制約を利用するという期待が存在します。アプリケーションの所有者は、必要に応じて、PATH処理の実装を確認する必要がある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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Freeman、T.、Housley、R.、Malpani、A.、Cooper、D。、およびW. Polk、「サーバーベースの証明書検証プロトコル（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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet 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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、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] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet 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] Adams、C.、Farrell、S.、Kause、T。、およびT. Mononen、「Internet 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.、Ashmore、S。、およびC. Wallace、「Trust Anchor Format」、RFC 5914、2010年6月。
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010.
[RFC5934] Housley、R.、Ashmore、S。、およびC. Wallace、「Trust Anchor Management Protocol（TAMP）」、RFC 5934、2010年8月。
Authors' Addresses
著者のアドレス
Raksha Reddy National Security Agency Suite 6599 9800 Savage Road Fort Meade, MD 20755
Raksha Reddy National Security Agency Suite 6599 9800 Savage Road Fort Meade、MD 20755
EMail: r.reddy@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean、VA 22102
EMail: cwallace@cygnacom.com