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）公開鍵証明書で認証パスにおける機関クリアランス制約証明書拡張の値は、有効なクリアランスを制約します主題。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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発行処理（例えば、の一部として検証することができたときのPKCにおけるクリアランス属性の配置は）1適している）、または2）などの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]はのACの連鎖を可能にしないので、機関クリアランス制約拡張は、証明機関（CA）ののPKCに現れるまたは局（AA）を属性することができます。機関クリアランス制約拡張はまた、トラストアンカー（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からのクリアランス値が受け入れられなければならない依拠当事者に指示することを望むかもしれません。例えば、セキュリティポリシーが（高度にCONFIDENTIAL CONFIDENTIAL、および一般的な）3つのセキュリティ分類値とアモコのために定義されている[RFC3114]に記載されているセキュリティポリシーを考えます。ちょうど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]).
この文書では、（[RFC5280]で）のPKCのための認証パス検証ルールを強化し、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]フリーウェアのコンパイラをサポートした最新のバージョンである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]にあるようSecurityCategoryが正確に示されています。この文書に含まれるモジュール暗黙タグ付けされたモジュールであるのに対し、そのモジュールは、明示的なタグ付けされたモジュールです。
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とsecurityCategoriesフィールドの意味を示します。
- 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.
- CLASSLISTは、セキュリティ分類を識別します。 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).
トラストアンカーの公開鍵を直接使用されている場合は、効果的なクリアランス（も証明書パスのための効果的なクリアランスと定義される）として使用すべきであれば、そのクリアランスは、トラストアンカーに関連付けられています。
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.
当局クリアランス制約証明書拡張は、ACまたはPKCの証明書パス内の最後の証明書のサブジェクトの主題のために許容されるべきである何クリアランス依拠当事者に示します。これは、トラストアンカー、CA PKC、またはAAのPKCにのみ意味があります。トラストアンカー、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またはTA、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.
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認証パスにおけるユーザ入力とTAおよび各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の中間に存在する全ての機関クリアランス制約。この計算を実行し、本明細書に記載のアルゴリズムから1と同じ結果を提供する任意の効果的なクリアランスの計算アルゴリズムは、この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.
許可-クリアランス：認証パスを処理するときに、権限クリアランス制約は、一つの状態変数に維持されます。処理が開始されると、許可・クリアランス権限クリアランス制約のユーザ入力が提供されていない場合は、ユーザーの入力値または特別な値にすべて-クリアランスを初期化されます。許可・クリアランス状態変数は、パス内の局クリアランス制約証明書拡張を含む中間PKCが処理されるたびに、トラストアンカーに関連付けられた第一の処理権限クリアランス制約によって更新され、。
When processing the end PKC, the value in the Clearance attribute in the end PKC is intersected with the permitted-clearances state variable.
エンドPKCを処理するときに、エンド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.
トラストアンカーが権限クリアランス制約拡張が含まれていない場合は、セクション4.1.1.3で続けます。そうでない場合は、PKCとしてトラストアンカーを処理することにより、インラインマクロとして第6節に記載された手順を実行します。
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.
効果的なクリアランスがX.がある中で、私たちはPOLICYIDを言ってみましょう
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の値を有する効果的なクリアランスのものCLASSLISTのビット1の値（1）（1）有効で、他のすべてのCLASSLISTビット実効クリアランスおよびPOLICYID X.割り当てに関連付けられた許可・クリアランスにおけるクリアランス構造の両方に割り当てますゼロ（0）の値を-clearance。
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.
CLASSLISTビットのいずれも有効なクリアランス内の1つ（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.
空集合は、単にSETを省略して表されることセクション7注記に記載されたアルゴリズムを使用して許可・クリアランスにPOLICYID Xのための効果的なクリアランスとsecurityCategoriesにsecurityCategoriesの交点に有効なクリアランスにsecurityCategoriesを設定します。
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にアサートされると、このセクションでは、認証パス処理について説明します。処理に関連がある一TA。 0以上のCAのPKC。 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）ACの対象のための有効なクリアランスを決定するために、PKCの認証パス及び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）すべての権限クリアランス制約AAのTAからPKCの証明書パスに存在します。この計算を実行し、本明細書に記載のアルゴリズムから1と同じ結果を提供する任意の効果的なクリアランスの計算アルゴリズムは、この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.
許可-クリアランス：権限のクリアランス制約は一つの状態変数で維持されています。処理が開始されると、許可・クリアランス権限クリアランス制約のユーザ入力が提供されていない場合は、ユーザの入力や特殊な値にすべて-クリアランスを初期化されます。許可・クリアランス状態変数は、次に処理される経路における機関クリアランス制約証明書拡張が含まれている（ACホルダーPKC以外の）各時間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証明経路とAC検証のために[RFC5755]のセクション5で説明されたアルゴリズムのために[RFC5280]のセクション6に記載PKC認証パス検証アルゴリズムに加えとして提示されます。また、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処理ルールを適用します。
6. Computing the Intersection of permitted-clearances and Authority Clearance Constraints Extension
6.許可-クリアランスと権限クリアランス制約拡張の交差点を計算
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に存在する場合、機関クリアランス制約証明書拡張の値を変数temp-クリアランスを設定します。一度、より多く現れる同じポリシーIDの一時-クリアランスを調べます。 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および許可-クリアランスが全クリアランス特別な値を含んで存在する場合、許可クリアランス割り当てるTEMP-クリアランスの値。
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.
- クリアランスに関連付けられPOLICYIDがTEMP-隙間に存在しない場合は、許可・クリアランス状態変数からpolicyIDを関連付けられたクリアランス構造を削除します。
- If the policyId is present in temp-clearances:
- POLICYIDは一時、クリアランスに存在する場合：
-- 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（1）である場合、すべてのCLASSLISTビットについて、CLASSLISTを割り当て許可-クリアランス状態変数にPOLICYID（1）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つ（1）CLASSLISTため、許可・クリアランス状態変数からPOLICYIDに関連付けられたクリアランス構造を削除し、処理securityCategoriesの次のステップを省略しています。
-- 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.
- 空のセットは、単にSETを省略して表現されることが許可され、クリアランスにPOLICYIDについては、セクション7ノートに記載許可-クリアランスおよびアルゴリズムを使用してTEMP-クリアランスにおけるPOLICYIDためsecurityCategoriesの交点にsecurityCategoriesを設定します。
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.
このセクションでは、これは、状態変数TEMP-セットを使用securityCategories AとBとの交点を計算する方法について説明します。また、一時的な変数XとYを使用しています
Set the SET temp-set to empty.
一時セット空にSETを設定します。
Set X = A and Y = B.
集合X = A及びY = B.
If SET X is empty (i.e., securityCategories is absent), return temp-set.
SET Xが空（すなわち、securityCategoriesが存在しない）である場合、戻り温度設定。
If SET Y is empty (i.e., securityCategories is absent), return temp-set.
SET Yは空である場合（すなわち、securityCategoriesが存在しない）、リターン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のすべての要素IFおよび場合、Xの各タイプのOIDおよびYにおけるそのタイプのOIDのためのすべての要素が同一である場合にのみ、一時セットにそれらの要素を追加し、XとYからこれらの要素を削除します注：同じタイプのOIDと指定された値を持つ要素は、X中に存在する場合、それはまたその逆も同じタイプのOIDと所定値とを持つY中に存在することを意味します。 XからとY.から要素を削除します。
If SET X is empty (i.e., securityCategories is absent), return temp-set.
SET Xが空（すなわち、securityCategoriesが存在しない）である場合、戻り温度設定。
If SET Y is empty (i.e., securityCategories is absent), return temp-set.
SET Yは空である場合（すなわち、securityCategoriesが存在しない）、リターンTEMPセット。
For every element (i.e., SecurityCategory) in the SET X, carry out the following steps:
SET Xの各要素（すなわち、SecurityCategory）のために、以下のステップを実行します。
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. SET Xの要素で型OIDと同じタイプのOIDとSET Yには要素が存在しない場合は、ステップ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.同じタイプのOIDと値を設定Yの要素がSET 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.
素子がSETの一時セットに存在しない場合a）に示すように、型OIDとSETの一時セットの値を含む要素を追加します。
3. If the processing semantics of type OID in the element in SET X is not known, go to step 5.
SET Xの要素内のタイプOIDの処理セマンティクスが知られていない3.場合は、手順5に進みます。
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）SET 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）SET Y.内の要素の値とSET Xの要素の値の型OID固有の交差点を実行します
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-セットに既に存在しない場合、一時セットの要素として型OIDと交差値を含む要素を追加した場合。
d) Continue to the next element in SET Y.
D）SET Y.の次の要素に進みます
5. If more elements remain in SET X, process the next element starting with step 1.
前記複数の要素は、SET X、プロセスのステップ1から始まる次の要素残っている場合。
Return temp-set.
戻り温度設定。
This RFC also includes a recommended securityCategories object as follows:
以下のように、このRFCはまた、推奨securityCategoriesオブジェクトが含まれています。
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.
証明書発行者は、CA証明書に、TAにおける権威のクリアランス制約のないことを認識しなければならない、または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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]クーパー、D.ら。アル。、「インターネット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]ファレル、S.、Housley氏、R.、およびS.ターナー、 "認可のためのインターネット属性証明書プロフィール"、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]ホフマン、P.およびJ. Schaad、X.509を使用して公開鍵インフラストラクチャのための「新しいASN.1モジュール（PKIX）RFC 5912、2010年6月。
[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.ポーク、 "インターネットX.509公開鍵インフラストラクチャ：資格証明書プロファイル"、RFC 3739、2004年3月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
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 }
ClearanceConstraints {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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) }
ID-AT-クリアランス、PKIXAttributeCertificate-2009 {ISO（1）同定された組織からのクリアランス（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID- MOD-属性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) } ;
EXTENSION、FROM SECURITY-CATEGORY PKIX-CommonTypes-2009 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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.
- 次は、クリアランスのための2002 ASN.1バージョンです。 - それは、利便性のために含まれています。
-- 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 -- }
- {{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.
- EXPLICITタグ[RFC5912]を使用する - モジュールSecurityCategoryモジュールから取り出されることに留意されたいです。 [RFC5912]から、コメントをASN.1から除去された - - クリアランスがインポートされなかった場合、本明細書に含まれ、次いで型に内在も除去することができた - エンコーディングに影響を与えることなく。
-- 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
- 当局のクリアランス制約証明書拡張のOID - と構文
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.
多くのおかげで、この文書への彼の貴重な貢献のためにマークSaaltinkに出かけます。
We would also like to thank Francis Dupont, Pasi Eronen, Adrian Farrel, Dan Romascanu, and Stefan Santesson for their reviews and comments.
我々はまた、彼らのレビューとコメントのためにフランシスデュポン、パシEronen、エードリアンファレル、ダンRomascanu、およびステファンSantessonに感謝したいと思います。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
ショーン・ターナーIECA株式会社3057ナトリーストリート、スイート106バージニア州フェアファクス22031 USA
EMail: turners@ieca.com
メールアドレス：turners@ieca.com
Santosh Chokhani CygnaCom Solutions, Inc.
満足度のご飯signakam solusansa、株式会社..
EMail: SChokhani@cygnacom.com
メールアドレス：SChokhani@cygnacom.com