[要約] RFC 5937は、証明書パス処理中に信頼アンカー制約を使用する方法についての規格です。その目的は、証明書の検証プロセスを強化し、信頼できる証明書パスの形成を確保することです。
Internet Engineering Task Force (IETF) S. Ashmore
Request for Comments: 5937 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
August 2010
Using Trust Anchor Constraints during Certification Path Processing
証明書パス処理中のトラストアンカー制約の使用
Abstract
概要
This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.
このドキュメントでは、証明書パスを検証するときに、トラストアンカーの公開キーに関連する情報を使用する方法について説明します。この情報は、トラストアンカーの使用を制限するために使用できます。通常、制約は、トラストアンカーを使用して検証された証明書パスに表示される証明書ポリシーと名前を制限するために使用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc5937.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5937で入手できます。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Identifying Trust Anchor Constraints ............................3
3. Using Trust Anchor Constraints during Certification Path
Processing ......................................................4
3.1. Inputs .....................................................4
3.2. Initialization .............................................4
3.3. Basic Certificate Processing ...............................6
3.4. Preparation for Certificate i+1 ............................6
3.5. Wrap-Up Procedure ..........................................6
4. Relationship to RFC 5280 ........................................6
5. Security Considerations .........................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Trust anchors are widely used to verify digital signatures and validate certification paths [RFC5280] [X.509]. They are required when validating certification paths. The Trust Anchor Format (TAF) specification [RFC5914] defines a means for limiting the scope in which a trust anchor may be used. [RFC5280] describes how to validate a certification path. The algorithm requires processing the name and key from a trust anchor. Usage of other information, including enforcement of constraints, is permitted but not required, and the processing rules are not specified (see Section 6.2 of RFC 5280).
トラストアンカーは、デジタル署名の検証と認証パスの検証に広く使用されています[RFC5280] [X.509]。証明書パスを検証するときに必要です。 Trust Anchor Format（TAF）仕様[RFC5914]は、トラストアンカーを使用できるスコープを制限する方法を定義しています。 [RFC5280]は、証明書パスを検証する方法を説明しています。このアルゴリズムでは、トラストアンカーからの名前とキーを処理する必要があります。制約の実施を含む他の情報の使用は許可されますが、必須ではなく、処理ルールは指定されていません（RFC 5280のセクション6.2を参照）。
This document defines a mechanism to identify constraints that should be enforced and the supplementary processing rules. The supplementary rules specify an additional input and extend the initialization procedures in the [RFC5280] path validation algorithm. Post-initialization processing steps are not affected.
このドキュメントでは、実施する必要のある制約と補足的な処理ルールを特定するメカニズムを定義しています。補足規則は、追加の入力を指定し、[RFC5280]パス検証アルゴリズムの初期化手順を拡張します。初期化後の処理ステップは影響を受けません。
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]で説明されているように解釈されます。
TAF supports three formats for representing trust anchor information: TrustAnchorInfo, Certificate, and TBSCertificate. In all three cases, trust anchor constraints may be represented as extensions. In the TrustAnchorInfo structure, certificate policies, policy constraints, name constraints, inhibit any policy, and basic constraints do not appear as extensions and instead appear as part of the CertPathControls field.
TAFは、トラストアンカー情報を表すために、TrustAnchorInfo、Certificate、TBSCertificateの3つの形式をサポートしています。 3つのケースすべてで、トラストアンカー制約は拡張として表される場合があります。 TrustAnchorInfo構造では、証明書ポリシー、ポリシー制約、名前制約、ポリシーの禁止、および基本制約は拡張として表示されず、代わりにCertPathControlsフィールドの一部として表示されます。
Extensions may be marked critical or not critical. When trust anchor constraints are enforced, clients MUST reject certification paths containing a trust anchor with unrecognized critical extensions. When trust anchor constraints are not enforced, clients MAY accept certification paths containing a trust anchor with unrecognized critical extensions. Information appearing in the CertPathControls field of a TrustAnchorInfo object MUST be processed, ensuring enforcement of the constraints indicated by this field in all cases.
拡張機能は、重要または重要でないとマークされる場合があります。トラストアンカーの制約が適用されている場合、クライアントは、認識されない重要な拡張を持つトラストアンカーを含む証明書パスを拒否する必要があります。トラストアンカーの制約が適用されていない場合、クライアントは、認識されない重要な拡張を持つトラストアンカーを含む証明書パスを受け入れることができます（MAY）。 TrustAnchorInfoオブジェクトのCertPathControlsフィールドに表示される情報を処理する必要があります。これにより、すべての場合にこのフィールドで示される制約が適用されます。
For some types of trust anchor constraints, there is a type mismatch between the input parameters for the certification path validation algorithm and the extension that contains the constraint. The certification path validation algorithm essentially defines the initial-any-policy-inhibit, initial-policy-mapping-inhibit, and initial-explicit-policy as Boolean values. The inhibitAnyPolicy and policyConstraints extensions that correspond to these inputs are expressed as integer values. In the steps described below, presence of an inhibitAnyPolicy extension results in the initial-any-policy-inhibit value being set to true. If a policyConstraints extension is present and contains a requireExplicitPolicy field, the initial-explicit-policy value is set to true. If a policyConstraints extension is present and contains an inhibitPolicyMapping field, the initial-policy-mapping-inhibit value is set to true.
一部のタイプのトラストアンカー制約では、証明書パス検証アルゴリズムの入力パラメーターと制約を含む拡張との間にタイプの不一致があります。証明書パス検証アルゴリズムは、基本的に、initial-any-policy-inhibit、initial-policy-mapping-inhibit、およびinitial-explicit-policyをブール値として定義します。これらの入力に対応するpreventAnyPolicyおよびpolicyConstraints拡張は、整数値として表されます。以下で説明する手順では、inhibitAnyPolicy拡張が存在すると、initial-any-policy-inhibit値がtrueに設定されます。 policyConstraints拡張が存在し、requireExplicitPolicyフィールドが含まれている場合、initial-explicit-policy値はtrueに設定されます。 policyConstraints拡張が存在し、inhibitPolicyMappingフィールドが含まれている場合、initial-policy-mapping-inhibit値はtrueに設定されます。
This algorithm assumes that the nine inputs defined in Section 6.1.1 of RFC 5280 are provided to the path processing logic, plus one additional variable:
このアルゴリズムは、RFC 5280のセクション6.1.1で定義されている9つの入力と、1つの追加変数がパス処理ロジックに提供されることを前提としています。
o enforceTrustAnchorConstraints: indicates if trust anchor constraints should be enforced
o enforceTrustAnchorConstraints：トラストアンカーの制約を適用する必要があるかどうかを示します
Conforming implementations are not required to support the setting of the enforceTrustAnchorConstraints input. If a conforming implementation does not support the setting of this flag, it MUST validate all certification paths using a value of TRUE for enforceTrustAnchorConstraints.
適合実装は、enforceTrustAnchorConstraints入力の設定をサポートする必要はありません。準拠する実装がこのフラグの設定をサポートしない場合は、enforceTrustAnchorConstraintsにTRUEの値を使用してすべての証明書パスを検証する必要があります。
If enforceTrustAnchorConstraints is false, no additional initialization steps are required.
enforceTrustAnchorConstraintsがfalseの場合、追加の初期化手順は必要ありません。
If enforceTrustAnchorConstraints is true, perform the following initialization steps described below. These steps (or equivalent) MUST be performed prior to initialization steps described in RFC 5280.
enforceTrustAnchorConstraintsがtrueの場合、以下に説明する次の初期化手順を実行します。これらの手順（または同等の手順）は、RFC 5280で説明されている初期化手順の前に実行する必要があります。
o If no subject distinguished name is associated with the trust anchor, path validation fails. The name may appear in the subject field of a Certificate or TBSCertificate structure or in the taName field of CertPathControls in a TrustAnchorInfo structure.
o トラストアンカーにサブジェクト識別名が関連付けられていない場合、パスの検証は失敗します。名前は、CertificateまたはTBSCertificate構造のサブジェクトフィールド、またはTrustAnchorInfo構造のCertPathControlsのtaNameフィールドに表示されます。
o If name constraints are associated with the trust anchor, set the initial-permitted-subtrees variable equal to the intersection of the permitted subtrees from the trust anchor and the user-provided initial-permitted-subtrees. If one of these two inputs is not provided, the initial-permitted-subtrees variable is set to the value that is available. If neither is provided, the initial-permitted-subtrees variable is set to an infinite set.
o 名前の制約がトラストアンカーに関連付けられている場合は、initial-permitted-subtrees変数を、トラストアンカーからの許可されたサブツリーとユーザー指定のinitial-permitted-subtreesの共通部分に等しく設定します。これらの2つの入力のいずれかが指定されていない場合、initial-permitted-subtrees変数は使用可能な値に設定されます。どちらも指定されていない場合、initial-permitted-subtrees変数は無限セットに設定されます。
o If name constraints are associated with the trust anchor, set the initial-excluded-subtrees variable equal to the union of the excluded subtrees from the trust anchor and the user-provided initial-excluded-subtrees. If one of these two inputs is not provided, the initial-excluded-subtrees variable is set to the value that is available. If neither is provided, the initial-excluded-subtrees variable is set to an empty set.
o 名前の制約がトラストアンカーに関連付けられている場合は、initial-excluded-subtrees変数を、トラストアンカーから除外されたサブツリーとユーザー指定のinitial-excluded-subtreesの和集合に等しく設定します。これら2つの入力のいずれかが指定されていない場合、initial-excluded-subtrees変数は使用可能な値に設定されます。どちらも指定されていない場合、initial-excluded-subtrees変数は空のセットに設定されます。
o If certificate policies are associated with the trust anchor, set the user-initial-policy-set variable equal to the intersection of the certificate policies associated with the trust anchor and the user-provided user-initial-policy-set. If one of these two inputs is not provided, the user-initial-policy-set variable is set to the value that is available. If neither is provided, the user-initial-policy-set variable is set to any-policy.
o 証明書ポリシーがトラストアンカーに関連付けられている場合は、トラストアンカーに関連付けられた証明書ポリシーとユーザー提供のuser-initial-policy-setの共通部分に等しいuser-initial-policy-set変数を設定します。これらの2つの入力のいずれかが指定されていない場合、user-initial-policy-set変数は使用可能な値に設定されます。どちらも指定されていない場合、user-initial-policy-set変数はany-policyに設定されます。
o If an inhibit any policy value of true is associated with the trust anchor (either in a CertPathControls or in an inhibitAnyPolicy extension) and the initial-any-policy-inhibit value is false, set the initial-any-policy-inhibit value to true.
o trueのいずれかのポリシー値の抑制がトラストアンカー（CertPathControlsまたはpreventAnyPolicy拡張のいずれか）に関連付けられており、initial-any-policy-inhibit値がfalseの場合、initial-any-policy-inhibit値をtrueに設定します。 。
o If a require explicit policy value of true is associated with the trust anchor (either in a CertPathControls or in a PolicyConstraints extension) and the initial-explicit-policy value is false, set the initial-explicit-policy value to true.
o 明示的なポリシーが必要なtrueの値がトラストアンカー（CertPathControlsまたはPolicyConstraints拡張機能のいずれか）に関連付けられており、initial-explicit-policy値がfalseの場合、initial-explicit-policy値をtrueに設定します。
o If an inhibit policy mapping value of true is associated with the trust anchor (either in a CertPathControls or in a PolicyConstraints extension) and the initial-policy-mapping-inhibit value is false, set the initial-policy-mapping-inhibit value to true.
o trueのポリシーマッピング禁止値がトラストアンカー（CertPathControlsまたはPolicyConstraints拡張機能のいずれか）に関連付けられており、initial-policy-mapping-inhibit値がfalseの場合、initial-policy-mapping-inhibit値をtrueに設定します。 。
o If a basic constraints extension is associated with the trust anchor and contains a pathLenConstraint value, set the max_path_length state variable equal to the pathLenConstraint value from the basic constraints extension.
o 基本制約拡張がトラストアンカーに関連付けられていて、pathLenConstraint値が含まれている場合は、max_path_length状態変数を、基本制約拡張のpathLenConstraint値と等しくなるように設定します。
This document does not require any augmentation of the basic certificate processing steps described in Section 6.1.3 of RFC 5280. However, some types of trust anchor constraints may have defined additional steps, for example, CMS Content Constraints or Authority Clearance Constraints.
このドキュメントでは、RFC 5280のセクション6.1.3で説明されている基本的な証明書処理手順を拡張する必要はありません。ただし、トラストアンカーの制約のタイプによっては、CMSコンテンツ制約やオーソリティクリアランス制約などの追加の手順が定義されている場合があります。
This document does not require any augmentation of the steps to prepare for processing of certificate i+1 described in Section 6.1.4 of RFC 5280. However, some types of trust anchor constraints may have defined additional steps, for example, CMS Content Constraints or Authority Clearance Constraints.
このドキュメントでは、RFC 5280のセクション6.1.4で説明されている証明書i + 1の処理を準備するための手順を追加する必要はありません。ただし、CMSコンテンツ制約や、権限クリアランスの制約。
This document does not require any augmentation of the wrap-up procedure steps described in Section 6.1.5 of RFC 5280. However, some types of trust anchor constraints may have defined additional steps, for example, CMS Content Constraints or Authority Clearance Constraints.
このドキュメントでは、RFC 5280のセクション6.1.5で説明されているラップアップ手順のステップを拡張する必要はありません。ただし、トラストアンカー制約のタイプによっては、CMSコンテンツ制約やオーソリティクリアランス制約などの追加のステップが定義されている場合があります。
The processing described above can be incorporated into an RFC 5280 implementation or be implemented as pre-processing of RFC 5280 inputs and post-processing of RFC 5280 outputs, i.e., as a wrapper around an RFC 5280 compliant implementation.
上記の処理は、RFC 5280実装に組み込むか、RFC 5280入力の前処理およびRFC 5280出力の後処理として、つまりRFC 5280準拠の実装のラッパーとして実装できます。
For name constraints and policy-related constraints, pre-processing can be used, provided the RFC 5280 implementation allows configuration of the user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, initial-any-policy-inhibit, initial-permitted-subtrees, and initial-excluded-subtrees input values. RFC 5280 does not define an input for path length constraints, so basic constraints cannot be implemented using pre-processing. It can be implemented as post-processing, provided the RFC 5280 implementation returns the certification path to enable the post-processor to perform the length check.
名前の制約とポリシー関連の制約については、RFC 5280実装でuser-initial-policy-set、initial-policy-mapping-inhibit、initial-explicit-policy、initial-anyの構成が許可されている場合、前処理を使用できます。 -policy-inhibit、initial-permitted-subtrees、およびinitial-excluded-subtreesの入力値。 RFC 5280はパス長の制約の入力を定義していないため、基本的な制約は前処理を使用して実装できません。 RFC 5280実装が認証パスを返し、ポストプロセッサが長さチェックを実行できるようにする場合は、後処理として実装できます。
Some types of trust anchor constraints may impose additional requirements on an RFC 5280 implementation to support pre-processing or post-processing to enforce trust anchor constraints.
一部のタイプのトラストアンカー制約は、トラストアンカー制約を実施するための前処理または後処理をサポートするために、RFC 5280実装に追加の要件を課す場合があります。
Implementations that do not enforce trust anchor constraints may accept some certification paths rejected by implementations that do enforce trust anchor constraints. For example, an application that does not enforce a certificate policy constraint included in a trust anchor may accept certificates issued under a certificate policy that provides a lower-than-required-level of assurance.
トラストアンカー制約を実施しない実装は、トラストアンカー制約を実施する実装によって拒否された一部の証明書パスを受け入れる場合があります。たとえば、トラストアンカーに含まれる証明書ポリシーの制約を適用しないアプリケーションは、必要条件よりも低いレベルの保証を提供する証明書ポリシーの下で発行された証明書を受け入れる場合があります。
Trust anchor information must be securely stored. Changes to trust anchor information can cause acceptance of certificates that should be rejected. For example, if a trust anchor definition is altered to remove a name constraint, applications may accept certificates containing names that should only be trusted in certificates that validate to a different trust anchor. Similarly, addition of inappropriate trust anchors to a trust anchor store can result in validation of certificates to a different trust anchor and with different constraints than intended.
トラストアンカー情報は安全に保存する必要があります。トラストアンカー情報を変更すると、拒否されるべき証明書が受け入れられる可能性があります。たとえば、トラストアンカーの定義を変更して名前の制約を削除すると、アプリケーションは、別のトラストアンカーに対して検証される証明書でのみ信頼される必要がある名前を含む証明書を受け入れる場合があります。同様に、不適切なトラストアンカーをトラストアンカーストアに追加すると、証明書が異なるトラストアンカーに検証され、意図したものとは異なる制約が課される可能性があります。
[RFC5914] and [RFC5934] provide additional security considerations regarding the preparation, storage, and usage of trust anchors. [RFC5280] provides additional security considerations regarding the usage of name constraints.
[RFC5914]および[RFC5934]は、トラストアンカーの準備、保存、および使用に関する追加のセキュリティの考慮事項を提供します。 [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月。
[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 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[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月。
[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.
[X.509] ITU-T勧告X.509（2005）| ISO / IEC 9594-8：2005、情報技術-オープンシステム相互接続-ディレクトリ：公開鍵および属性証明書フレームワーク。
Authors' Addresses
著者のアドレス
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade, MD 20755 USA
Sam Ashmore National Security Agency Suite 6751 9800 Savage Road Fort Meade、MD 20755 USA
EMail: srashmo@radium.ncsc.mil
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean, VA 22102 USA
Carl Wallace Cygnacom Solutions Suite 5400 7925 Jones Branch Drive McLean、VA 22102 USA
EMail: cwallace@cygnacom.com