[要約] RFC 5913は、クリアランス属性と権限クリアランス制約証明書拡張に関する規格であり、セキュリティポリシーの制約を表現するために使用されます。この規格の目的は、証明書にセキュリティポリシーの情報を追加し、アクセス制御を強化することです。
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5913 IECA
Category: Standards Track S. Chokhani
ISSN: 2070-1721 Cygnacom Solutions
June 2010
Clearance Attribute and Authority Clearance Constraints Certificate Extension
クリアランス属性と権限のクリアランス制約証明書拡張
Abstract
概要
This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject.
このドキュメントでは、クリアランス属性の構文とセマンティクスと、X.509証明書の権限クリアランスが拡張を制約することを定義します。クリアランス属性は、被験者が保有するクリアランスを示すために使用されます。クリアランス属性は、公開キー証明書の拡張件名または属性証明書の属性フィールドに表示される場合があります。当局のクリアランスは、信託アンカー（TA）、認証局（CA）公開証明書、および属性権限（AA）の公認キー証明書における証明書アンカー（TA）、特定の主題の認定パスの公開鍵証明書の証明書拡張値を制約します。主題。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5913.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5913で取得できます。
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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. ASN.1 Syntax Notation ......................................4
2. Clearance Attribute .............................................4
3. Authority Clearance Constraints Certificate Extension ...........5
4. Processing Clearance and Authority Clearance Constraints
in a PKC ........................................................6
4.1. Collecting Constraints .....................................7
4.1.1. Certification Path Processing .......................7
4.1.1.1. Inputs .....................................8
4.1.1.2. Initialization .............................8
4.1.1.3. Basic Certificate Processing ...............8
4.1.1.4. Preparation for Certificate i+1 ............9
4.1.1.5. Wrap-up Procedure ..........................9
4.1.1.5.1. Wrap Up Clearance ...............9
4.1.1.6. Outputs ...................................10
5. Clearance and Authority Clearance Constraints
Processing in AC ...............................................10
5.1. Collecting Constraints ....................................11
5.1.1. Certification Path Processing ......................11
5.1.1.1. Inputs ....................................11
5.1.1.2. Initialization ............................11
5.1.1.3. Basic PKC Processing ......................12
5.1.1.4. Preparation for Certificate i+1 ...........12
5.1.1.5. Wrap-up Procedure .........................12
5.1.1.5.1. Wrap Up Clearance ..............12
5.1.1.6. Outputs ...................................12
6. Computing the Intersection of permitted-clearances and
Authority Clearance Constraints Extension ......................12
7. Computing the Intersection of securityCategories ...............13
8. Recommended securityCategories .................................15
9. Security Considerations ........................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
Appendix A. ASN.1 Module ..........................................17
Acknowledgments ...................................................19
Organizations that have implemented a security policy can issue certificates that include an indication of the clearance values held by the subject. The Clearance attribute indicates the security policy, the clearance levels held by the subject, and additional authorization information held by the subject. This specification makes use of the ASN.1 syntax for clearance from [RFC5912].
セキュリティポリシーを実装した組織は、主題が保持しているクリアランス値の指標を含む証明書を発行できます。クリアランス属性は、セキュリティポリシー、主題が保持しているクリアランスレベル、および主題が保有する追加の承認情報を示します。この仕様では、[RFC5912]からのクリアランスにASN.1構文を使用します。
The Clearance attribute may be placed in the subject directory attributes extension of a Public Key Certificate (PKC) or may be placed in a separate attribute certificate (AC).
クリアランス属性は、公開キー証明書（PKC）の拡張属性属性に配置されるか、別の属性証明書（AC）に配置される場合があります。
The placement of the Clearance attribute in PKCs is suitable 1) when the clearance information is relatively static and can be verified as part of the PKC issuance process (e.g., using local databases) or 2) when the credentials such as PKCs need to be revoked when the clearance information changes. The Clearance attribute may also be included to simplify the infrastructure, to reduce the infrastructure design cost, or to reduce the infrastructure operations cost. An example of placement of the Clearance attribute in PKCs in operational Public Key Infrastructure (PKI) is the Defense Messaging Service. An example of placement of attributes in PKCs is Qualified Certificates [RFC3739].
PKCのクリアランス属性の配置は適切です1）クリアランス情報が比較的静的であり、PKCの発行プロセスの一部として検証できる場合（ローカルデータベースなど）またはPKCなどの資格情報を取り消す必要がある場合クリアランス情報が変更されたとき。クリアランス属性は、インフラストラクチャを簡素化したり、インフラストラクチャの設計コストを削減したり、インフラストラクチャの運用コストを削減したりするために含めることもできます。運用上の公開キーインフラストラクチャ（PKI）におけるPKCにおけるクリアランス属性の配置の例は、防衛メッセージングサービスです。PKCに属性の配置の例は、適格な証明書です[RFC3739]。
The placement of Clearance attributes in ACs is desirable when the clearance information is relatively dynamic and changes in the clearance information do not require revocation of credentials such as PKCs, or the clearance information cannot be verified as part of the PKC issuance process.
ACSのクリアランス属性の配置は、クリアランス情報が比較的動的であり、クリアランス情報の変更がPKCなどの資格情報の取り消しを必要としない場合、またはPKC発行プロセスの一部としてクリアランス情報を検証できない場合に望ましいです。
Since [RFC5755] does not permit a chain of ACs, the Authority Clearance Constraints extension may only appear in the PKCs of a Certification Authority (CA) or Attribute Authority (AA). The Authority Clearance Constraints extension may also appear in a trust anchor (TA) or may be associated with a TA.
[RFC5755]はACSのチェーンを許可していないため、当局のクリアランス制約拡張は、認証機関（CA）または属性権限（AA）のPKCにのみ現れることがあります。当局のクリアランス制約の拡張は、Trust Anchor（TA）にも表示されるか、TAに関連付けられている場合があります。
Some organizations have multiple TAs, CAs, and/or AAs, and these organizations may wish to indicate to relying parties which clearance values from a particular TA, CA, or AA should be accepted. For example, consider the security policies described in [RFC3114], where a security policy has been defined for Amoco with three security classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and GENERAL). To constrain a CA for just one security classification, the Authority Clearance Constraints certificate extension would be included in the CA's PKC.
一部の組織には複数のTA、CA、および/またはAAがあり、これらの組織は、特定のTA、CA、またはAAからのクリアランス値を受け入れる必要がある当事者に依存することを望んでいる場合があります。たとえば、[RFC3114]に記載されているセキュリティポリシーを検討します。ここでは、3つのセキュリティ分類値（非常に機密、機密、および一般）でAMOCOに対してセキュリティポリシーが定義されています。1つのセキュリティ分類のみをCAを制約するために、当局のクリアランス制約証明書延長がCAのPKCに含まれます。
Cross-certified domains can also make use of the Authority Clearance Constraints certificate extension to indicate which clearance values should be acceptable to relying parties.
クロス認定ドメインは、当局のクリアランス制約証明書拡張を使用して、どのクリアランス値が当事者に依存するべきであるかを示すこともできます。
This document augments the certification path validation rules for PKCs (in [RFC5280]) and ACs (in [RFC5755]).
このドキュメントは、PKCS（[RFC5280]）およびACS（[RFC5755]）の認証パス検証ルールを強化します。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. All X.509 AC [RFC5755] extensions are defined using ASN.1 [X.680]. Note that [X.680] is the 2002 version of ASN.1, which is the most recent version with freeware compiler support.
すべてのX.509 PKC [RFC5280]拡張機能は、ASN.1 [X.680]を使用して定義されます。すべてのX.509 AC [RFC5755]拡張機能は、ASN.1 [X.680]を使用して定義されます。[X.680]は、Freewareコンパイラサポートを備えた最新のバージョンであるASN.1の2002バージョンであることに注意してください。
The Clearance attribute in a certificate indicates the clearances held by the subject. It uses the clearance attribute syntax, whose semantics are defined in [RFC5755], in the Attributes field. A certificate MUST include either zero or one instance of the Clearance attribute. If the Clearance attribute is present, it MUST contain a single value.
証明書のクリアランス属性は、被験者が保有するクリアランスを示します。セマンティクスが[RFC5755]で属性フィールドで定義されているクリアランス属性構文を使用します。証明書には、クリアランス属性のゼロまたは1つのインスタンスのいずれかを含める必要があります。クリアランス属性が存在する場合、単一の値を含める必要があります。
The following object identifier identifies the Clearance attribute (either in the subject directory attributes extension of a PKC or in the Attributes field of an AC):
次のオブジェクト識別子は、クリアランス属性を識別します（件名ディレクトリ属性のPKCの拡張またはACの属性フィールドのいずれか）を識別します。
id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
ds(5) attributeTypes(4) clearance(55) }
The ASN.1 syntax for the Clearance attribute is defined in [RFC5912] and that RFC provides the normative definition. The ASN.1 syntax for Clearance attribute is as follows:
クリアランス属性のASN.1構文は[RFC5912]で定義されており、RFCは規範的定義を提供します。クリアランス属性のASN.1構文は次のとおりです。
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory
{{ SupportedSecurityCategories }} OPTIONAL
}
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
SECURITY-CATEGORY ::= TYPE-IDENTIFIER
SecurityCategory { SECURITY-CATEGORY:Supported }::= SEQUENCE {
type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}),
value [1] EXPLICIT SECURITY-CATEGORY.&Type
({Supported}{@type})
}
NOTE: SecurityCategory is shown exactly as it is in [RFC5912]. That module is an EXPLICIT tagged module, whereas the module contained in this document is an IMPLICIT tagged module.
注：セキュリティカテゴリは[RFC5912]のように正確に表示されます。このモジュールは明示的なタグ付きモジュールですが、このドキュメントに含まれるモジュールは暗黙のタグ付きモジュールです。
The Clearance attribute takes its meaning from Section 4.4.6 of [RFC5755], which is repeated here for convenience:
クリアランス属性は、[RFC5755]のセクション4.4.6からその意味を取ります。これは、便利なためにここで繰り返されます。
- policyId identifies the security policy to which the clearance relates. The policyId indicates the semantics of the classList and securityCategories fields.
- PolicyIDは、クリアランスが関連するセキュリティポリシーを特定します。PolicyIDは、クラスリストとセキュリティカテゴリのフィールドのセマンティクスを示しています。
- classList identifies the security classifications. Six basic values are defined in bit positions 0 through 5, and more may be defined by an organizational security policy.
- クラスリストは、セキュリティ分類を識別します。6つの基本値はビット位置0〜5で定義され、さらに多くの基準が組織のセキュリティポリシーで定義される場合があります。
- securityCategories provides additional authorization information.
- SecurityCategoriesは、追加の承認情報を提供します。
If a trust anchor's public key is used directly, then the Clearance associated with the trust anchor, if any, should be used as the effective clearance (also defined as effective-clearance for a certification path).
Trust Anchorの公開キーが直接使用される場合、トラストアンカーに関連付けられたクリアランスは、効果的なクリアランスとして使用する必要があります（認定パスの効果的なクリアランスとしても定義されます）。
The Authority Clearance Constraints certificate extension indicates to the relying party what clearances should be acceptable for the subject of the AC or the subject of the last certificate in a PKC certification path. It is only meaningful in a trust anchor, a CA PKC, or an AA PKC. A trust anchor, CA PKC, or AA PKC MUST include either zero or one instance of the Authority Clearance Constraints certificate extension. The Authority Clearance Constraints certificate extension MAY be critical or non-critical.
当局のクリアランス制約証明書延長は、PKC認定パスのACまたは最後の証明書の主題に対してどのクリアランスが受け入れられるべきかを依存している当事者に示します。それは、信頼のアンカー、CA PKC、またはAA PKCでのみ意味があります。Trust Anchor、Ca PKC、またはAA PKCには、ゼロまたは1つのインスタンスのいずれかのインスタンスが、証明書拡張拡張のいずれかを含める必要があります。権限のクリアランス制約証明書の延長は、重要または非批判的である場合があります。
Absence of this certificate extension in a TA, a CA PKC, or an AA PKC indicates that clearance of the subject of the AC or the subject of the last certificate in a PKC certification path containing the TA, the CA, or the AA is not constrained by the respective TA, CA, or AA.
TA、CA PKC、またはAA PKCでのこの証明書延長の欠如は、ACの被験者またはCA、CA、またはAAを含むPKC認定パスにおける最後の証明書の主題のクリアランスがないことを示しています。それぞれのTA、CA、またはAAによって制約されています。
The following object identifier identifies the Authority Clearance Constraints certificate extension:
次のオブジェクト識別子は、権限のクリアランス制約証明書拡張を識別します。
id-pe-authorityClearanceConstraints OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pe(1) 21 }
The ASN.1 syntax for the Authority Clearance Constraints certificate extension is as follows:
権限のクリアランス制約証明書拡張のASN.1構文は次のとおりです。
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF
Clearance
The syntax for the Authority Clearance Constraints certificate extension contains Clearances that the CA or the AA asserts. The sequence MUST NOT include more than one entry with the same policyId. This constraint is enforced during Clearance and Authority Clearance Constraints Processing as described below. If more than one entry with the same policyId is present in the Authority Clearance Constraints certificate extension, the certification path is rejected.
権限のクリアランス制約証明書延長の構文には、CAまたはAAが主張するクリアランスが含まれています。シーケンスには、同じPolicyIDを使用して複数のエントリを含めてはなりません。この制約は、以下で説明するように、クリアランスおよび当局のクリアランス制約の処理中に実施されます。当局のクリアランス制約証明書延長に同じPolicyIDを持つ複数のエントリが存在する場合、認証パスは拒否されます。
This section describes the certification path processing when Clearance is asserted in the PKC under consideration.
このセクションでは、検討中のPKCでクリアランスが主張された場合の認証パス処理について説明します。
User input, the Authority Clearance Constraints certificate extension, and Clearance attribute processing determines the effective clearance (henceforth called effective-clearance) for the end PKC. User input and the Authority Clearance Constraints certificate extension in the TA and in each PKC (up to but not including the end PKC) in a PKC certification path impact the effective-clearance. If there is more than one path to the end PKC, each path is processed independently. The process involves two steps:
ユーザーの入力、当局のクリアランス制約証明書の拡張、およびクリアランス属性処理により、最終PKCの効果的なクリアランス（以降、有効クリアランスと呼ばれる）が決定されます。ユーザー入力と権限のクリアランス制約は、PKC認定パスの各PKC（最終PKCまでは含まれていませんが）の証明書拡張拡張を効果的なクリアランスに影響します。終了PKCへのパスが複数ある場合、各パスは個別に処理されます。プロセスには2つのステップが含まれます。
1) collecting the Authority Clearance Constraints; and
1) 当局のクリアランスの制約の収集。と
2) using the Authority Clearance Constraints in the certification path and the Clearance in the end PKC to determine the effective-clearance for the subject of the end PKC.
2) 認証パスの権限クリアランスの制約と最終PKCのクリアランスを使用して、最終PKCの主題の効果的なクリアランスを決定します。
Assuming a certification path consisting of n PKCs, the effective-clearance for the subject of the end PKC is the intersection of 1) the Clearance attribute in the subject PKC, 2) the Authority Clearance Constraints, if present, in the trust anchor, 3) user input, and 4) all Authority Clearance Constraints present in n-1 intermediate PKCs. Any effective-clearance calculation algorithm that performs this calculation and provides the same outcome as the one from the algorithm described herein is considered compliant with the requirements of this RFC.
N PKCからなる認定パスを想定すると、最終PKCの主題の効果的なクリアランスは、1）被験者PKCのクリアランス属性、2）信頼アンカーに存在する場合の権限クリアランスの制約、3の交差点です。）ユーザー入力、および4）N-1中間PKCに存在するすべての権限クリアランスの制約。この計算を実行し、本明細書に記載されているアルゴリズムの結果と同じ結果を提供する効果的なクリアランス計算アルゴリズムは、このRFCの要件に準拠していると見なされます。
When processing a certification path, Authority Clearance Constraints are maintained in one state variable: permitted-clearances. When processing begins, permitted-clearances is initialized to the user input value or the special value all-clearances if Authority Clearance Constraints user input is not provided. The permitted-clearances state variable is updated by first processing Authority Clearance Constraints associated with the trust anchor, and then each time an intermediate PKC that contains an Authority Clearance Constraints certificate extension in the path is processed.
認証パスを処理する場合、権限のクリアランスの制約は、1つの状態変数、つまり許可されたクリアランスで維持されます。処理が開始されると、許可されたクリアランスは、ユーザーの入力値または権限クリアランスの制約ユーザー入力が提供されていない場合、ユーザー入力値または特別な値のすべてのクリアンスに初期化されます。許可されたクリアランス状態変数は、信頼アンカーに関連付けられた最初の処理機関のクリアランス制約によって更新され、その後、パスの権限クリアランス制約証明書拡張を含む中間のPKCが処理されます。
When processing the end PKC, the value in the Clearance attribute in the end PKC is intersected with the permitted-clearances state variable.
END PKCを処理する場合、End PKCのクリアランス属性の値は、許可されたクリアランス状態変数と交差します。
The output of Clearance attribute and Authority Clearance Constraint certificate extension processing is the effective-clearance (which could also be an empty list), and a status indicator of either success or failure. If the status indicator is failure, then the process also returns a reason code.
クリアランス属性と権限のクリアランス制約証明書の拡張処理の出力は、効果的なクリアランス（空のリストでもある可能性があります）であり、成功または失敗のステータスインジケーターです。ステータスインジケータが障害の場合、プロセスは理由コードも返します。
Authority Clearance Constraints are collected from the user input, the trust anchor, and the intermediate PKCs in a certification path.
権限のクリアランスの制約は、ユーザー入力、トラストアンカー、および認定パス内の中間PKCから収集されます。
When processing Authority Clearance Constraints certificate extensions for the purposes of validating a Clearance attribute in the end PKC, the processing described in this section or an equivalent algorithm MUST be performed in addition to the certification path validation.
処理当局のクリアランス制約は、最終PKCのクリアランス属性を検証する目的で証明書拡張を制約する場合、このセクションまたは同等のアルゴリズムで説明した処理を、認証パス検証に加えて実行する必要があります。
The processing is presented as an addition to the certification path validation algorithm described in Section 6 of [RFC5280]. Note that this RFC is fully consistent with [RFC5280]; however, it augments [RFC5280] with the following steps:
処理は、[RFC5280]のセクション6で説明されている認証パス検証アルゴリズムへの追加として提示されます。このRFCは[RFC5280]と完全に一致していることに注意してください。ただし、次の手順で[RFC5280]を強化します。
o Ability to provide and process Authority Clearance Constraints as an additional input to the certification path processing engine with Trust anchor information.
o 信頼できるアンカー情報を使用した認証パス処理エンジンへの追加の入力として、権限のクリアランスの制約を提供および処理する能力。
o Requirement to process Authority Clearance Constraints present with trust anchor information.
o 信頼できるアンカー情報が存在する権限のクリアランスの制約を処理するための要件。
User input may include an Authority Clearance Constraints structure or omit it.
ユーザーの入力には、権限のクリアランスの制約構造が含まれるか、それを省略する場合があります。
Trust anchor information may include the Authority Clearance Constraints structure to specify Authority Clearance Constraints for the trust anchor. In other words, the trust anchor may be constrained or unconstrained.
トラストアンカー情報には、信頼アンカーの権限クリアランスの制約を指定するための権限クリアランスの制約構造が含まれる場合があります。言い換えれば、信頼のアンカーは制約されているか、制約されていない場合があります。
If the user input includes Authority Clearance Constraints, set permitted-clearances to the input value; otherwise, set permitted-clearances to the special value all-clearances.
ユーザーの入力に権限のクリアランスの制約が含まれている場合、入力値に許可されたクリアンスを設定します。それ以外の場合は、特別な価値のすべてのクリアランスに許可されたクリアランスを設定します。
Examine the permitted-clearances for the same Policy ID appearing more then once. If a policyId appears more than once in the permitted-clearances state variable, set effective-clearance to an empty list, set error code to "multiple instances of same clearance", and exit with failure.
同じポリシーIDの許可されたクリアランスを一度登場することを調べます。許可されたクリアンスの状態変数にPolicyIDが複数回表示される場合、空のリストに効果的なクリアランスを設定し、エラーコードを「同じクリアランスの複数のインスタンス」に設定し、障害とともに終了します。
If the trust anchor does not contain an Authority Clearance Constraints extension, continue at Section 4.1.1.3. Otherwise, execute the procedure described in Section 6 as an in-line macro by treating the trust anchor as a PKC.
Trust Anchorに権限のクリアランス制約の拡張が含まれていない場合は、セクション4.1.1.3で続行します。それ以外の場合は、セクション6で説明されている手順をインラインマクロとして実行して、信頼アンカーをPKCとして扱います。
If the PKC is the last PKC (i.e., certificate n), skip the steps listed in this section. Otherwise, execute the procedure described in Section 6 as an in-line macro.
PKCが最後のPKC（つまり、証明書n）である場合、このセクションにリストされている手順をスキップします。それ以外の場合は、セクション6で説明されている手順をインラインマクロとして実行します。
No additional action associated with the Clearance attribute or the Authority Clearance Constraints certificate extensions is taken during this phase of certification path validation as described in Section 6 of [RFC5280].
[RFC5280]のセクション6で説明されているように、クリアランス属性または当局のクリアランス制約証明書拡張に関連する追加のアクションは、認証パス検証のこの段階で採用されません。
To complete the processing, perform the following steps for the last PKC (i.e., certificate n).
処理を完了するには、最後のPKC（つまり、証明書N）の次の手順を実行します。
Examine the PKC and verify that it does not contain more than one instance of the Clearance attribute. If the PKC contains more than one instance of the Clearance attribute, set effective-clearance to an empty list, set the error code to "multiple instances of an attribute", and exit with failure.
PKCを調べ、クリアランス属性の複数のインスタンスが含まれていないことを確認します。PKCにクリアランス属性の複数のインスタンスが含まれている場合、空のリストに効果的なクリアランスを設定し、エラーコードを「属性の複数のインスタンス」に設定し、障害とともに終了します。
If the Clearance attribute is not present in the end PKC, set effective-clearance to an empty list and exit with success.
クリアランス属性が最終PKCに存在しない場合、空のリストに効果的なクリアランスを設定し、成功して終了します。
Set effective-clearance to the Clearance attribute in the end PKC.
最終PKCのクリアランス属性に効果的なクリアランスを設定します。
Examine effective-clearance and verify that it does not contain more than one value. If effective-clearance contains more than one value, set effective-clearance to an empty list, set error code to "multiple values", and exit with failure.
効果的な承認を調べ、複数の値が含まれていないことを確認します。効果的なクリアランスに複数の値が含まれている場合、空のリストに効果的なクリアランスを設定し、エラーコードを「複数の値」に設定し、障害とともに終了します。
If permitted-clearances is an empty list, set effective-clearance to an empty list and exit with success.
許可されたクリアランスが空のリストである場合、空のリストに効果的なクリアランスを設定し、成功して終了します。
If permitted-clearances has the special value all-clearances, exit with success.
許可されたクリアランスに特別な価値がある場合は、成功を収めて終了します。
Let us say policyId in effective-clearance is X.
効果的なクリアランスでPolicidIDがXであるとしましょう。
If the policyId X in effective-clearance is absent from the permitted-clearances, set effective-clearance to an empty list and exit with success.
効果的なクリアランスにあるPolicyID Xが許可されたクリアランスに存在しない場合、空のリストに効果的なクリアランスを設定し、成功して終了します。
Assign those classList bits in effective-clearance a value of one (1) that have a value of one (1) both in effective-clearance and in the clearance structure in permitted-clearances associated with policyId X. Assign all other classList bits in effective-clearance a value of zero (0).
効果的なクリアランスでこれらのクラスリストビットを、有効なクリアランスの両方とクリアランス構造の両方で1の値を1つの値に割り当てます。 - ゼロ（0）の値を繰り返します。
If none of the classList bits have a value of one (1) in effective-clearance, set effective-clearance to an empty list and exit with success.
クラスリストビットのいずれにも1つの値がない場合、効果的なクリアランスは、空のリストに効果的なクリアランスを設定し、成功して終了します。
Set the securityCategories in effective-clearance to the intersection of securityCategories in effective-clearance and securityCategories for policyId X in permitted-clearances using the algorithm described in Section 7. Note that an empty SET is represented by simply omitting the SET.
セクション7で説明されているアルゴリズムを使用して、許可されたクリアランスの有効クリアランスとセキュリティカテゴリのセキュリティカテゴリとセキュリティカテゴリのセキュリティカテゴリの交差点に有効なクリアランスを設定して設定します。空のセットは、単にセットを省略して表されることに注意してください。
Exit with success.
成功して終了します。
If certification path validation processing succeeds, effective-clearance contains the subject's effective clearance for this certification path. Processing also returns success or failure indication and reason for failure, if applicable.
認証パス検証処理が成功した場合、効果的なクリアランスには、この認証パスに対する被験者の効果的なクリアランスが含まれています。また、処理は、該当する場合、成功または失敗の兆候と失敗の理由を返します。
This section describes the certification path processing when Clearance is asserted in an AC. Relevant to processing are: one TA; 0 or more CA PKCs; 0 or 1 AA PKC; and 1 AC.
このセクションでは、ACでクリアランスが主張されている場合の認証パス処理について説明します。処理に関連するのは次のとおりです。0以上のCA PKCS;0または1 AA PKC;および1 AC。
User input, Authority Clearance Constraints certificate extension, and Clearance attribute processing determine the effective clearance (henceforth called effective-clearance) for the subject of the AC. User input and the Authority Clearance Constraints certificate extensions in the TA and in each PKC (up to and including the AA PKC) in a certification path impact the effective-clearance. If there is more than one path to the AA PKC, each path is processed independently. The process involves two steps:
ユーザーの入力、権限のクリアランス制約証明書拡張、およびクリアランス属性処理により、ACの対象の有効クリアランス（以降、有効クリアランスと呼ばれる）が決定されます。ユーザー入力と権限のクリアランス制約は、認証パスのTAおよび各PKC（AA PKCまで）の証明書拡張を効果的なクリアランスに影響します。AA PKCへのパスが複数ある場合、各パスは個別に処理されます。プロセスには2つのステップが含まれます。
1) collecting the Authority Clearance Constraints; and
1) 当局のクリアランスの制約の収集。と
2) using the Authority Clearance Constraints in the PKC certification path and the Clearance in the AC to determine the effective-clearance for the subject of the AC.
2) PKC認証パスの権限クリアランスの制約とACのクリアランスを使用して、ACの主題の効果的なクリアランスを決定します。
The effective-clearance for the subject of the AC is the intersection of 1) the Clearance attribute in the subject AC, 2) the Authority Clearance Constraints, if present, in trust anchor, 3) user input, and 4) all Authority Clearance Constraints present in the PKC certification path from the TA to the AA. Any effective-clearance calculation algorithm that performs this calculation and provides the same outcome as the one from the algorithm described herein is considered compliant with the requirements of this RFC.
ACの主題の効果的なクリアランスは、1）被験者ACのクリアランス属性、2）権限のクリアランスの制約、存在する場合、信頼アンカー、3）ユーザー入力、および4）すべての権限クリアランスの制約です。TAからAAへのPKC認定パスに存在します。この計算を実行し、本明細書に記載されているアルゴリズムの結果と同じ結果を提供する効果的なクリアランス計算アルゴリズムは、このRFCの要件に準拠していると見なされます。
The Authority Clearance Constraints are maintained in one state variable: permitted-clearances. When processing begins, permitted-clearances is initialized to user input or the special value all-clearances if Authority Clearance Constraints user input is not provided. The permitted-clearances state variable is updated by first processing the Authority Clearance Constraints associated with the trust anchor, and then each time a PKC (other than AC holder PKC) that contains an Authority Clearance Constraints certificate extension in the path is processed.
当局のクリアランスの制約は、1つの状態変数、つまり許可されたクリアランスで維持されます。処理が開始されると、許可されたクリアランスは、ユーザーの入力またはユーザーの入力が提供されていない場合、ユーザー入力または特別な値のすべてのクリアンスに初期化されます。許可されたクリアンスの状態変数は、信頼アンカーに関連する権限のクリアランス制約を最初に処理することにより更新され、次にパスに権限のクリアランス制約証明書延長を含むPKC（ACホルダーPKC以外）が処理されます。
When processing the AC, the value in the Clearance attribute in the AC is intersected with the permitted-clearances state variable.
ACを処理する場合、ACのクリアランス属性の値は、許可されたクリアランス状態変数と交差します。
The output of Clearance attribute and Authority Clearance Constraint certificate extension processing is the effective-clearance, which could also be an empty list; and success or failure with a reason code for failure.
クリアランス属性と権限のクリアランス制約証明書拡張処理の出力は、効果的なクリアランスであり、空のリストでもあります。失敗の理由コードを伴う成功または失敗。
Authority Clearance Constraints are collected from the user input, the trust anchor, and all the PKCs in the AA PKC certification path.
権限のクリアランスの制約は、ユーザー入力、トラストアンカー、およびAA PKC認定パスのすべてのPKCから収集されます。
When processing Authority Clearance Constraints certificate extensions for the purpose of validating a Clearance attribute in the AC, the processing described in this section or an equivalent algorithm MUST be performed in addition to the certification path validation. The processing is presented as an addition to the PKC certification path validation algorithm described in Section 6 of [RFC5280] for the AA PKC certification path and the algorithm described in Section 5 of [RFC5755] for the AC validation. Also see the note related to [RFC5280] augmentation in Section 4.1.1.
ACのクリアランス属性を検証する目的で、当局のクリアランス制約証明書の拡張機能は、このセクションまたは同等のアルゴリズムで説明する処理を実行する必要があります。処理は、AA PKC認証パスの[RFC5280]のセクション6で説明されているPKC認定パス検証アルゴリズムと、AC検証の[RFC5755]のセクション5で説明されているアルゴリズムに追加されます。セクション4.1.1の[RFC5280]の増強に関連するメモも参照してください。
Same as Section 4.1.1.1.
セクション4.1.1.1と同じ。
In addition, let us assume that the PKC certification path for the AA consists of n certificates.
さらに、AAのPKC認証パスはN証明書で構成されていると仮定します。
Same as Section 4.1.1.2.
セクション4.1.1.2と同じ。
Same as Section 4.1.1.3 except that the logic is applied to all n PKCs.
ロジックがすべてのN PKCに適用されることを除いて、セクション4.1.1.3と同じです。
Same as Section 4.1.1.4.
セクション4.1.1.4と同じ。
To complete the processing, perform the following steps for the AC.
処理を完了するには、ACの次の手順を実行します。
Examine the AC and verify that it does not contain more than one instance of the Clearance attribute. If the AC contains more than one instance of the Clearance attribute, set effective-clearance to an empty list, set the error code to "multiple instances of an attribute", and exit with failure.
ACを調べ、クリアランス属性の複数のインスタンスが含まれていないことを確認します。ACにクリアランス属性の複数のインスタンスが含まれている場合、空のリストに効果的なクリアランスを設定するには、エラーコードを「属性の複数のインスタンス」に設定し、障害とともに終了します。
If the Clearance attribute is not present in the AC, set effective-clearance to an empty list and exit with success.
ACにクリアランス属性が存在しない場合は、空のリストに効果的なクリアランスを設定し、成功して終了します。
Set effective-clearance to the Clearance attribute in the AC.
ACのクリアランス属性に効果的なクリアランスを設定します。
Same as Section 4.1.1.5.1.
セクション4.1.1.5.1と同じ。
Same as Section 4.1.1.6.
セクション4.1.1.6と同じ。
In addition, apply AC processing rules described in Section 5 of [RFC5755].
さらに、[RFC5755]のセクション5で説明したAC処理ルールを適用します。
Examine the PKC and verify that it does not contain more than one instance of the Authority Clearance Constraints extension. If the PKC contains more than one instance of Authority Clearance Constraints extension, set effective-clearance to an empty list, set error code to "multiple extension instances", and exit with failure.
PKCを調べ、権限のクリアランス制約の拡張の複数のインスタンスが含まれていないことを確認します。PKCに権限のクリアランス制約の拡張が複数ある場合、空のリストに効果的なクリアランスを設定し、エラーコードを「複数の拡張インスタンス」に設定し、障害とともに終了します。
If the Authority Clearance Constraints certificate extension is not present in the PKC, no action is taken, and the permitted-clearances value is unchanged.
権限のクリアランス制約証明書拡張がPKCに存在しない場合、アクションは実行されず、許可されたクリアンス値は変更されません。
If the Authority Clearance Constraints certificate extension is present in the PKC, set the variable temp-clearances to the value of the Authority Clearance Constraints certificate extension. Examine the temp-clearances for the same Policy ID appearing more then once. If a policyId appears more than once in the temp-clearances state variable, set effective-clearance to an empty list, set error code to "multiple instances of same clearance", and exit with failure.
権限のクリアランス制約証明書拡張がPKCに存在する場合、可変温度クリアランスを当局クリアランス制約証明書拡張の価値に設定します。同じポリシーIDが一度登場する同じポリシーIDの一時的なクリアランスを調べます。Temp Celleancesの状態変数にPolicyIDが複数回表示される場合、空のリストに効果的なクリアランスを設定し、エラーコードを「同じクリアランスの複数のインスタンス」に設定し、障害とともに終了します。
If the Authority Clearance Constraints certificate extension is present in the PKC and permitted-clearances contains the all-clearances special value, then assign permitted-clearances the value of temp-clearances.
権限のクリアランス制約証明書の拡張がPKCに存在し、許可されたクリアンスにすべてのクリアランスが含まれている場合、許可されたクリアランスに温度クリアランスの値を割り当てます。
If the Authority Clearance Constraints certificate extension is present in the PKC and permitted-clearances does not contain the all-clearances special value, take the intersection of temp-clearances and permitted-clearances by repeating the following steps for each clearance in the permitted-clearances state variable:
権限のクリアランス制約証明書延長がPKCに存在し、許可されたクリアンスに全クリアランスが含まれていない場合、許可されたクリアランスの各クリアランスについて次の手順を繰り返すことにより、温度クリアランスと許可されたクリアンスの交差点を取ります状態変数：
- If the policyId associated with the clearance is absent in the temp-clearances, delete the clearance structure associated with the policyID from the permitted-clearances state variable.
- クリアランスに関連付けられているPolicidIDが温度クリアンスに存在しない場合、許可されたクリアンス状態変数からPolicidIDに関連付けられたクリアランス構造を削除します。
- If the policyId is present in temp-clearances:
- PolicidIDが温度を識別して存在する場合：
-- For every classList bit, assign the classList bit a value of one (1) for the policyId in the permitted-clearances state variable if the bit is one (1) in both the permitted-clearances state variable and the temp-clearances for that policyId; otherwise, assign the bit a value of zero (0).
- すべてのクラスリストビットに対して、許可されたクリアランス状態変数の1つである場合、許可されたクリアランス状態変数のPolicyIDにクラスリストビットの値を1つの値に割り当てます。そのpolicyid;それ以外の場合は、ビットをゼロ（0）の値を割り当てます。
-- If no bits are one (1) for the classList, delete the clearance structure associated with the policyId from the permitted-clearances state variable and skip the next step of processing securityCategories.
- クラスリストのビットが1つない場合、許可されたクリアンスの状態変数からPolicidIDに関連付けられたクリアランス構造を削除し、セキュリティカテゴリを処理する次のステップをスキップします。
-- For the policyId in permitted-clearances, set the securityCategories to the intersection of securityCategories for the policyId in permitted-clearances and in temp-clearances using the algorithm described in Section 7. Note that an empty SET is represented by simply omitting the SET.
- 許可されたクリアランスのPolicyIDについては、セクション7で説明したアルゴリズムを使用して、許可されたクリアランスおよび温度クリアンスのPolicyIDのセキュリティカテゴリの交差点にセキュリティカテゴリを設定します。。
The algorithm described here has the idempotent, associative, and commutative properties.
ここで説明するアルゴリズムには、等身、連想、および通勤特性があります。
This section describes how to compute the intersection of securityCategories A and B. It uses the state variable temp-set. It also uses temporary variables X and Y.
このセクションでは、セキュリティカテゴリAとBの交差点を計算する方法について説明します。状態変数温度セットを使用します。また、一時的な変数XとYを使用します。
Set the SET temp-set to empty.
設定された温度セットを空に設定します。
Set X = A and Y = B.
x = aとy = Bを設定します
If SET X is empty (i.e., securityCategories is absent), return temp-set.
セットxが空の場合（つまり、セキュリティカテゴリが存在しない場合）、tempセットを返します。
If SET Y is empty (i.e., securityCategories is absent), return temp-set.
設定yが空の場合（つまり、セキュリティカテゴリが存在しない場合）、tempセットを返します。
For each type OID in X, if all the elements for the type OID in X and if and only if all the elements for that type OID in Y are identical, add those elements to temp-set and delete those elements from X and Y. Note: identical means that if the element with the type OID and given value is present in X, it is also present in Y with the same type OID and given value and vice versa. Delete the elements from X and from Y.
Xの各タイプOIDについて、XのタイプOIDのすべての要素、およびそのタイプOIDのすべての要素が同一である場合にのみ、それらの要素を温度セットに追加し、XとYからそれらの要素を削除します。注：同一のことは、タイプOIDと与えられた値を持つ要素がXに存在する場合、同じタイプのOIDでYに存在し、与えられた値とその逆も同様であることを意味します。xとyから要素を削除します。
If SET X is empty (i.e., securityCategories is absent), return temp-set.
セットxが空の場合（つまり、セキュリティカテゴリが存在しない場合）、tempセットを返します。
If SET Y is empty (i.e., securityCategories is absent), return temp-set.
設定yが空の場合（つまり、セキュリティカテゴリが存在しない場合）、tempセットを返します。
For every element (i.e., SecurityCategory) in the SET X, carry out the following steps:
セットxのすべての要素（つまり、セキュリティカテゴリ）について、次の手順を実行します。
1. If there is no element in SET Y with the same type OID as the type OID in the element from SET X, go to step 5.
1. セットYに、セットXの要素のタイプOIDと同じタイプOIDを持つ要素がない場合は、ステップ5に進みます。
2. If there is an element in SET Y with the same type OID and value as in the element in SET X, carry out the following steps:
2. SET Yに同じタイプのOIDを持つ要素があり、セットXの要素と同じ値がある場合は、次の手順を実行します。
a) If the element is not present in the SET temp-set, add an element containing the type OID and the value to the SET temp-set.
a) 要素が設定されたTEMPセットに存在しない場合は、タイプOIDとSET TEMPセットに値を含む要素を追加します。
3. If the processing semantics of type OID in the element in SET X is not known, go to step 5.
3. セットXの要素のタイプOIDの処理セマンティクスが不明な場合は、ステップ5に進みます。
4. For each element in SET Y, do the following:
4. セットyの各要素について、次のことを行います。
a) If the type OID of the element in SET Y is not the same as the element in SET X being processed, go to step 4.d.
a) セットyの要素の型OIDが、セットxの要素が処理されるのと同じでない場合は、ステップ4.dに進みます。
b) Perform type-OID-specific intersection of the value in the element in SET X with the value in the element in SET Y.
b) セットXの要素の値のタイプとOF特異的交差点を実行し、セットYの要素の値を実行します。
c) If the intersection is not empty, and the element representing the type OID and intersection value is not already present in temp-set, add the element containing the type OID and intersection value as an element to temp-set.
c) 交差点が空でなく、タイプOIDと交差点値を表す要素がTEMPセットにまだ存在していない場合、Tempセットの要素としてタイプOIDと交差値を含む要素を追加します。
d) Continue to the next element in SET Y.
d) セットYの次の要素に進みます。
5. If more elements remain in SET X, process the next element starting with step 1.
5. より多くの要素がセットXに残っている場合は、ステップ1から始まる次の要素を処理します。
Return temp-set.
TEMPセットを返します。
This RFC also includes a recommended securityCategories object as follows:
このRFCには、次のように推奨されるセキュリティカテゴリオブジェクトも含まれています。
recommended-category SECURITY-CATEGORY ::=
{ BIT STRING IDENTIFIED BY OID }
The above structure is provided as an example. To use this structure, the object identifier (OID) needs to be registered and the semantics of the bits in the bit string need to be enumerated.
上記の構造は例として提供されています。この構造を使用するには、オブジェクト識別子（OID）を登録する必要があり、ビット文字列のビットのセマンティクスを列挙する必要があります。
Note that type-specific intersection of two values for this type will be simply setting the bits that are set in both values. If the resulting intersection has none of the bits set, the intersection is considered empty.
このタイプの2つの値のタイプ固有の交差は、両方の値に設定されたビットを単純に設定することに注意してください。結果の交差点にビットがセットされていない場合、交差点は空と見なされます。
Certificate issuers must recognize that absence of the Authority Clearance Constraints in a TA, in a CA certificate, or in an AA certificate means that in terms of the clearance, the subject Authority is not constrained.
証明書発行者は、TA、CA証明書、またはAA証明書に当局のクリアランスの制約がないことを認識しなければなりません。
Absence of the Clearance attribute in a certificate means that the subject has not been assigned any clearance.
証明書にクリアランス属性がないことは、被験者がクリアランスを割り当てられていないことを意味します。
If there is no Clearance associated with a TA, it means that the TA has not been assigned any clearance.
TAに関連するクリアランスがない場合、TAがクリアランスを割り当てられていないことを意味します。
If the local security policy considers the clearance held by a subject or those supported by a CA or AA to be sensitive, then the Clearance attribute or Authority Clearance Constraints should only be included if the subject's and Authority's certificates can be privacy protected. Also in this case, distribution of trust anchors and associated Authority Clearance Constraints extension or Clearance must also be privacy protected.
現地のセキュリティポリシーが、被験者またはCAまたはAAによってサポートされているものが保有するクリアランスを機密性があると見なす場合、クリアランス属性または当局のクリアランスの制約は、被験者と権限の証明書がプライバシー保護を受けることができる場合にのみ含める必要があります。また、この場合、信託アンカーの分布と関連する権限のクリアランスの制約拡張またはクリアランスもプライバシー保護されている必要があります。
[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. et. al., "Internet X.509 Public Key Infrastructure Certificate and Certification Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D。et。al。、「Internet X.509公開キーインフラストラクチャ証明書および認定取消リスト（CRL）プロファイル」、RFC 5280、2008年5月。
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5755] Farrell、S.、Housley、R。、およびS. Turner、「認証のためのインターネット属性証明書プロファイル」、RFC 5755、2010年1月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) RFC 5912, June 2010.
[RFC5912] Hoffman、P。およびJ. Schaad、 "X.509（PKIX）RFC 5912、2010年6月を使用した公開キーインフラストラクチャの新しいASN.1モジュール。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One.
[X.680] ITU-T推奨X.680（2002）|ISO/IEC 8824-1：2002。情報技術 - 抽象的な構文表記1。
[RFC3114] Nicolls, W., "Implementing Company Classification Policy with the S/MIME Security Label", RFC 3114, May 2002.
[RFC3114] Nicolls、W。、「S/MIMEセキュリティラベルを使用した会社分類ポリシーの実装」、RFC 3114、2002年5月。
[RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", RFC 3739, March 2004.
[RFC3739] Santesson、S.、Nystrom、M。、およびT. Polk、「インターネットX.509公開キーインフラストラクチャ：資格のある証明書プロファイル」、RFC 3739、2004年3月。
This appendix provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in X.680.
この付録は、X.680で定義されているASN.1を使用して、この仕様で説明されている構造の規範ASN.1定義を提供します。
ClearanceConstraints { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0) 46 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
輸入
-- IMPORTS from [RFC5912]
- [RFC5912]からのインポート
id-at-clearance, Clearance
FROM PKIXAttributeCertificate-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-02(47)
}
-- IMPORTS from [RFC5912]
- [RFC5912]からのインポート
EXTENSION, SECURITY-CATEGORY
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)
}
;
-- Clearance attribute OID and syntax
- クリアランス属性OIDおよび構文
-- The following is a 2002 ASN.1 version for clearance.
-- It is included for convenience.
-- id-at-clearance OBJECT IDENTIFIER ::=
-- { joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance (55) }
-- Clearance ::= SEQUENCE {
-- policyId OBJECT IDENTIFIER,
-- classList ClassList DEFAULT {unclassified},
-- securityCategories SET OF SecurityCategory
-- {{SupportSecurityCategories }} OPTIONAL
-- }
-- ClassList ::= BIT STRING {
-- unmarked (0),
-- unclassified (1),
-- restricted (2),
-- confidential (3),
-- secret (4),
-- topSecret (5)
-- }
-- SECURITY-CATEGORY ::= TYPE-IDENTIFIER
-- NOTE that the module SecurityCategory is taken from a module
-- that uses EXPLICIT tags [RFC5912]. If Clearance was not imported
-- from [RFC5912] and the comments were removed from the ASN.1
-- contained herein, then the IMPLICIT in type could also be removed
-- with no impact on the encoding.
-- SecurityCategory { SECURITY-CATEGORY:Supported } ::= SEQUENCE {
-- type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}),
-- value [1] EXPLICIT SECURITY-CATEGORY.&Type
-- ({Supported}{@type})
-- }
-- Authority Clearance Constraints certificate extension OID
-- and syntax
id-pe-clearanceConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pe(1) 21 }
authorityClearanceConstraints EXTENSION ::= {
SYNTAX AuthorityClearanceConstraints
IDENTIFIED BY id-pe-clearanceConstraints
}
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance
END
終わり
Acknowledgments
謝辞
Many thanks go out to Mark Saaltink for his valuable contributions to this document.
この文書への貴重な貢献について、Mark Saaltinkに感謝します。
We would also like to thank Francis Dupont, Pasi Eronen, Adrian Farrel, Dan Romascanu, and Stefan Santesson for their reviews and comments.
また、フランシス・デュポン、パシ・エロネン、エイドリアン・ファレル、ダン・ロマスカヌ、ステファン・サンテッソンのレビューとコメントに感謝します。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA、Inc。3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA
EMail: turners@ieca.com
Santosh Chokhani CygnaCom Solutions, Inc.
Santosh Chokhani Cygnacom Solutions、Inc。
EMail: SChokhani@cygnacom.com