[要約] RFC 5755は、認証のためのインターネット属性証明書プロファイルに関するものであり、要約すると、属性証明書の構造と使用方法を定義しています。目的は、属性証明書を使用して認証情報を提供し、アクセス制御や認可のための信頼性のある方法を提供することです。
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 5755 Trinity College Dublin
Obsoletes: 3281 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 S. Turner
IECA
January 2010
An Internet Attribute Certificate Profile for Authorization
承認用のインターネット属性証明書プロファイル
Abstract
概要
This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281.
この仕様は、インターネットプロトコルでX.509属性証明書を使用するためのプロファイルを定義しています。属性証明書は、相互運用性の幅広い目標と、運用および保証の要件の広い範囲をカバーする幅広いアプリケーションと環境で使用できます。このドキュメントの目的は、幅広い相互運用性と限定された特別な目的の要件を必要とする汎用アプリケーションの共通ベースラインを確立することです。このプロファイルは、インターネット電子メール、IPsec、およびWWWセキュリティアプリケーションの属性証明書のサポートに重点を置いています。このドキュメントはRFC 3281を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc5755.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5755で入手できます。
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標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
1.2. AC Path Delegation .........................................5
1.3. Attribute Certificate Distribution ("Push" vs. "Pull") .....6
1.4. Document Structure .........................................7
2. Terminology .....................................................7
3. Requirements ....................................................8
4. Attribute Certificate Profile ...................................9
4.1. X.509 Attribute Certificate Definition ....................10
4.2. Profile of Standard Fields ................................12
4.2.1. Version ............................................13
4.2.2. Holder .............................................13
4.2.3. Issuer .............................................14
4.2.4. Signature ..........................................14
4.2.5. Serial Number ......................................14
4.2.6. Validity Period ....................................15
4.2.7. Attributes .........................................15
4.2.8. Issuer Unique Identifier ...........................16
4.2.9. Extensions .........................................16
4.3. Extensions ................................................17
4.3.1. Audit Identity .....................................17
4.3.2. AC Targeting .......................................18
4.3.3. Authority Key Identifier ...........................19
4.3.4. Authority Information Access .......................19
4.3.5. CRL Distribution Points ............................20
4.3.6. No Revocation Available ............................20
4.4. Attribute Types ...........................................21
4.4.1. Service Authentication Information .................21
4.4.2. Access Identity ....................................22
4.4.3. Charging Identity ..................................23
4.4.4. Group ..............................................23
4.4.5. Role ...............................................23
4.4.6. Clearance ..........................................24
4.5. Profile of AC Issuer's PKC ................................26
5. Attribute Certificate Validation ...............................27
6. Revocation .....................................................28
7. Optional Features ..............................................29
7.1. Attribute Encryption ......................................29
7.2. Proxying ..................................................31
7.3. Use of ObjectDigestInfo ...................................32
7.4. AA Controls ...............................................33
8. Security Considerations ........................................35
9. IANA Considerations ............................................36
10. References ....................................................37
10.1. Reference Conventions ....................................37
10.2. Normative References .....................................37
10.3. Informative References ...................................38
Appendix A. Object Identifiers ....................................40
Appendix B. ASN.1 Module ..........................................41
Appendix C. Errata Report Submitted to RFC 3281 ...................47
Appendix D. Changes since RFC 3281 ................................48
X.509 public key certificates (PKCs) [X.509-1997] [X.509-2000] [PKIXPROF] bind an identity and a public key. An attribute certificate (AC) is a structure similar to a PKC; the main difference being that the AC contains no public key. An AC may contain attributes that specify group membership, role, security clearance, or other authorization information associated with the AC holder.
X.509公開鍵証明書（PKC）[X.509-1997] [X.509-2000] [PKIXPROF]は、IDと公開鍵をバインドします。属性証明書（AC）は、PKCに似た構造です。主な違いは、ACには公開鍵が含まれていないことです。 ACには、グループメンバーシップ、ロール、セキュリティクリアランス、またはAC所有者に関連付けられているその他の承認情報を指定する属性を含めることができます。
The syntax for the AC is defined in Recommendation X.509, making the term "X.509 certificate" ambiguous.
ACの構文は勧告X.509で定義されているため、「X.509証明書」という用語はあいまいです。
Some people constantly confuse PKCs and ACs. An analogy may make the distinction clear. A PKC can be considered to be like a passport: it identifies the holder, tends to last for a long time, and should not be trivial to obtain. An AC is more like an entry visa: it is typically issued by a different authority and does not last for as long a time. As acquiring an entry visa typically requires presenting a passport, getting a visa can be a simpler process.
一部の人々は常にPKCとACを混同しています。類推によって区別が明確になる場合があります。 PKCはパスポートのようなものと見なすことができます。これは所有者を識別し、長期間続く傾向があり、取得するのは簡単ではありません。 ACは入国ビザに似ています。通常、別の機関が発行し、有効期間は長くありません。通常、入国ビザを取得するにはパスポートを提示する必要があるため、ビザの取得はより簡単なプロセスです。
Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.
承認情報は、PKC拡張に配置するか、別の属性証明書（AC）に配置できます。 PKCに許可情報を配置することは、2つの理由から通常望ましくありません。第1に、承認情報の有効期間は、IDと公開鍵のバインディングと同じではないことがよくあります。許可情報がPKC拡張に配置されると、一般的な結果として、PKCの有効期間が短くなります。第2に、PKC発行者は通常、承認情報に対して権限を持ちません。これにより、PKC発行者が信頼できるソースから認証情報を取得するための追加の手順が発生します。
For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes.
これらの理由により、多くの場合、承認情報をPKCから分離する方が適切です。ただし、承認情報もIDにバインドする必要があります。 ACはこのバインディングを提供します。単にデジタル署名された（または認定された）IDと属性のセットです。
An AC may be used with various security services, including access control, data origin authentication, and non-repudiation.
ACは、アクセス制御、データ発信元認証、否認防止など、さまざまなセキュリティサービスで使用できます。
PKCs can provide an identity to access control decision functions. However, in many contexts, the identity is not the criterion that is used for access control decisions; rather, the role or group-membership of the accessor is the criterion used. Such access control schemes are called role-based access control.
PKCは、制御決定機能にアクセスするためのIDを提供できます。ただし、多くのコンテキストでは、アイデンティティはアクセス制御の決定に使用される基準ではありません。むしろ、アクセサの役割またはグループメンバーシップが使用される基準です。このようなアクセス制御スキームは、役割ベースのアクセス制御と呼ばれます。
When making an access control decision based on an AC, an access control decision function may need to ensure that the appropriate AC holder is the entity that has requested access. One way in which the linkage between the request or identity and the AC can be achieved is the inclusion of a reference to a PKC within the AC and the use of the private key corresponding to the PKC for authentication within the access request.
ACに基づいてアクセス制御決定を行う場合、アクセス制御決定機能は、適切なAC所有者がアクセスを要求したエンティティであることを確認する必要がある場合があります。要求またはIDとACの間のリンクを達成できる1つの方法は、AC内のPKCへの参照を含めることと、アクセス要求内の認証のためにPKCに対応する秘密鍵を使用することです。
ACs may also be used in the context of a data origin authentication service and a non-repudiation service. In these contexts, the attributes contained in the AC provide additional information about the signing entity. This information can be used to make sure that the entity is authorized to sign the data. This kind of checking depends either on the context in which the data is exchanged or on the data that has been digitally signed.
ACは、データ発信元認証サービスと否認防止サービスのコンテキストでも使用できます。これらのコンテキストでは、ACに含まれる属性は、署名エンティティに関する追加情報を提供します。この情報を使用して、エンティティにデータへの署名が許可されていることを確認できます。この種のチェックは、データが交換されるコンテキスト、またはデジタル署名されたデータに依存します。
This document obsoletes [RFC3281]. Changes since [RFC3281] are listed in Appendix D.
このドキュメントは廃止されました[RFC3281]。 [RFC3281]以降の変更点は付録Dに記載されています。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The X.509 standard [X.509-2000] defines authorization as the "conveyance of privilege from one entity that holds such privilege, to another entity". An AC is one authorization mechanism.
X.509標準[X.509-2000]は、承認を「そのような特権を保持する1つのエンティティから別のエンティティへの特権の伝達」と定義しています。 ACは認証メカニズムの1つです。
An ordered sequence of ACs could be used to verify the authenticity of a privilege asserter's privilege. In this way, chains or paths of ACs could be employed to delegate authorization.
順序付けられたACのシーケンスを使用して、特権アサーターの特権の信頼性を検証できます。このようにして、承認の委任にACのチェーンまたはパスを使用できます。
Since the administration and processing associated with such AC chains is complex and the use of ACs in the Internet today is quite limited, it is RECOMMENDED that implementations of this specification not use AC chains. Other (future) specifications may address the use of AC chains. This specification deals with the simple cases, where one authority issues all of the ACs for a particular set of attributes. However, this simplification does not preclude the use of several different authorities, each of which manages a different set of attributes. For example, group membership may be included in one AC issued by one authority, and security clearance may be included in another AC issued by another authority.
このようなACチェーンに関連する管理と処理は複雑であり、今日のインターネットでのACの使用は非常に制限されているため、この仕様の実装ではACチェーンを使用しないことをお勧めします。他の（将来の）仕様はACチェーンの使用に対処するかもしれません。この仕様は、1つの機関が特定の属性セットに対してすべてのACを発行するという単純なケースを扱います。ただし、この単純化は、それぞれが異なる属性のセットを管理するいくつかの異なる権限の使用を排除するものではありません。たとえば、グループメンバーシップを1つの機関が発行した1つのACに含め、セキュリティクリアランスを別の機関が発行した別のACに含めることができます。
This means that conformant implementations are only REQUIRED to be able to process a single AC at a time. Processing of more than one AC, one after another, may be necessary. Note however, that validation of an AC MAY require validation of a chain of PKCs, as specified in [PKIXPROF].
これは、適合した実装が一度に1つのACを処理できることのみが必要であることを意味します。複数のACを次々と処理する必要がある場合があります。ただし、ACの検証には、[PKIXPROF]で指定されているPKCのチェーンの検証が必要になる場合があります。
As discussed above, ACs provide a mechanism to securely provide authorization information to, for example, access control decision functions. However, there are a number of possible communication paths for ACs.
上記のように、ACは、たとえばアクセス制御決定機能に認証情報を安全に提供するメカニズムを提供します。ただし、ACにはいくつかの可能な通信パスがあります。
In some environments, it is suitable for a client to "push" an AC to a server. This means that no new connections between the client and server are required. It also means that no search burden is imposed on servers, which improves performance and that the AC verifier is only presented with what it "needs to know". The "push" model is especially suitable in inter-domain cases where the client's rights should be assigned within the client's "home" domain.
一部の環境では、クライアントがACをサーバーに「プッシュ」するのに適しています。つまり、クライアントとサーバー間の新しい接続は必要ありません。また、サーバーに検索負荷がかからないため、パフォーマンスが向上し、ACベリファイアには「知る必要がある」ものだけが表示されます。 「プッシュ」モデルは、クライアントの「ホーム」ドメイン内でクライアントの権限を割り当てる必要があるドメイン間ケースに特に適しています。
In other cases, it is more suitable for a client to simply authenticate to the server and for the server to request or "pull" the client's AC from an AC issuer or a repository. A major benefit of the "pull" model is that it can be implemented without changes to the client or to the client-server protocol. The "pull" model is especially suitable for inter-domain cases where the client's rights should be assigned within the server's domain, rather than within the client's domain.
他の場合では、クライアントがサーバーに対して単純に認証し、サーバーがAC発行者またはリポジトリからクライアントのACを要求または「プル」する方が適しています。 「プル」モデルの主な利点は、クライアントまたはクライアント/サーバープロトコルを変更せずに実装できることです。 「プル」モデルは、クライアントの権限をクライアントのドメイン内ではなくサーバーのドメイン内に割り当てる必要があるドメイン間ケースに特に適しています。
There are a number of possible exchanges involving three entities: the client, the server, and the AC issuer. In addition, a directory service or other repository for AC retrieval MAY be supported.
3つのエンティティ（クライアント、サーバー、AC発行者）が関与する可能な交換がいくつかあります。さらに、AC取得用のディレクトリサービスまたはその他のリポジトリがサポートされる場合があります。
Figure 1 shows an abstract view of the exchanges that may involve ACs. This profile does not specify a protocol for these exchanges.
図1は、ACが関係する可能性のある交換の抽象的なビューを示しています。このプロファイルは、これらの交換のプロトコルを指定していません。
+--------------+
| | Server Acquisition
| AC issuer +<---------------------------+
| | |
+--+-----------+ |
^ |
| Client |
| Acquisition |
v v
+--+-----------+ +--+------------+
| | AC "push" | |
| Client +<------------------------| Server |
| | (part of app. protocol) | |
+--+-----------+ +--+------------+
^ ^
| Client | Server
| Lookup +--------------+ | Lookup
| | | |
+-------------->+ Repository +<--------+
| |
+--------------+
Figure 1: AC Exchanges
図1：AC交換
Section 2 defines some terminology. Section 3 specifies the requirements that this profile is intended to meet. Section 4 contains the profile of the X.509 AC. Section 5 specifies rules for AC validation. Section 6 specifies rules for AC revocation checks. Section 7 specifies optional features that MAY be supported; however, support for these features is not required for conformance to this profile. Finally, the appendices contain the list of object identifiers (OIDs) required to support this specification and an ASN.1 module.
セクション2では、いくつかの用語を定義します。セクション3は、このプロファイルが満たすことを意図した要件を指定します。セクション4には、X.509 ACのプロファイルが含まれています。セクション5では、AC検証のルールを指定します。セクション6では、AC失効チェックのルールを指定します。セクション7は、サポートされる可能性があるオプション機能を指定します。ただし、これらの機能のサポートは、このプロファイルへの準拠には必要ありません。最後に、付録には、この仕様とASN.1モジュールをサポートするために必要なオブジェクト識別子（OID）のリストが含まれています。
For simplicity, we use the terms client and server in this specification. This is not intended to indicate that ACs are only to be used in client-server environments. For example, ACs may be used in the Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 context, where the mail user agent would be both a "client" and a "server" in the sense the terms are used here.
簡単にするために、この仕様ではクライアントとサーバーという用語を使用します。これは、ACがクライアント/サーバー環境でのみ使用されることを示すものではありません。たとえば、ACは、Secure / Multipurpose Internet Mail Extensions（S / MIME）v3.2コンテキストで使用できます。ここで、メールユーザーエージェントは、ここで使用されている意味で「クライアント」と「サーバー」の両方になります。 。
Term Meaning
用語意味
AA Attribute Authority, the entity that issues the AC, synonymous in this specification with "AC issuer".
AA属性機関、ACを発行するエンティティ。この仕様では「AC発行者」と同義です。
AC Attribute Certificate.
AC属性証明書。
AC user Any entity that parses or processes an AC.
ACユーザーACを解析または処理するエンティティ。
AC verifier Any entity that checks the validity of an AC and then makes use of the result.
ACベリファイアACの有効性を確認し、その結果を利用するエンティティ。
AC issuer The entity that signs the AC: synonymous in this specification with "AA".
AC発行者ACに署名するエンティティ：この仕様では「AA」と同義。
AC holder The entity indicated (perhaps indirectly) in the Holder field of the AC.
AC保有者ACの保有者フィールドに（おそらく間接的に）示されたエンティティ。
Client The entity that is requesting the action for which authorization checks are to be made.
クライアント許可検査が行われるアクションを要求しているエンティティー。
Proxying In this specification, Proxying is used to mean the situation where an application server acts as an application client on behalf of a user. Proxying here does not mean granting of authority.
プロキシこの仕様では、プロキシは、アプリケーションサーバーがユーザーの代わりにアプリケーションクライアントとして機能する状況を意味するために使用されます。ここでのプロキシは、権限の付与を意味するものではありません。
PKC Public Key Certificate - uses the ASN.1 type Certificate defined in X.509 and profiled in RFC 5280. This (non-standard) acronym is used in order to avoid confusion about the term "X.509 certificate".
PKC公開鍵証明書-X.509で定義され、RFC 5280でプロファイルされたASN.1タイプの証明書を使用します。この（非標準の）頭字語は、「X.509証明書」という用語の混乱を避けるために使用されます。
Server The entity that requires that the authorization checks are made.
サーバー許可検査が行われることを要求するエンティティー。
This AC profile meets the following requirements.
このACプロファイルは、次の要件を満たしています。
Time/Validity requirements:
時間/有効性の要件：
1. Support for short-lived as well as long-lived ACs. Typical short-lived validity periods might be measured in hours, as opposed to months for PKCs. Short validity periods allow ACs to be useful without a revocation mechanism.
1. 寿命の短いACと寿命の長いACのサポート。典型的な短命の有効期間は、PKCの月ではなく、時間で測定される場合があります。有効期間が短いため、ACは失効メカニズムがなくても便利です。
Attribute Types:
属性タイプ：
2. Issuers of ACs should be able to define their own attribute types for use within closed domains.
2. ACの発行者は、クローズドドメイン内で使用する独自の属性タイプを定義できる必要があります。
3. Some standard attribute types, which can be contained within ACs, should be defined. Examples include "access identity", "group", "role", "clearance", "audit identity", and "charging identity".
3. ACに含めることができるいくつかの標準属性タイプを定義する必要があります。例としては、「アクセスID」、「グループ」、「役割」、「クリアランス」、「監査ID」、「課金ID」などがあります。
4. Standard attribute types should be defined in a manner that permits an AC verifier to distinguish between uses of the same attribute in different domains. For example, the "Administrators group" as defined by "Baltimore" and the "Administrators group" as defined by "SPYRUS" should be easily distinguished.
4. 標準の属性タイプは、AC検証者が異なるドメインでの同じ属性の使用を区別できるように定義する必要があります。たとえば、「Baltimore」で定義されている「管理者グループ」と「SPYRUS」で定義されている「管理者グループ」は簡単に区別できます。
Targeting of ACs:
ACのターゲティング：
5. It should be possible to "target" an AC at one, or a small number of, servers. This means that a trustworthy non-target server will reject the AC for authorization decisions.
5. ACを1つまたは少数のサーバーに「ターゲット設定」できるようにする必要があります。これは、信頼できる非ターゲットサーバーが承認決定のためにACを拒否することを意味します。
Push vs. Pull
プッシュとプル
6. ACs should be defined so that they can either be "pushed" by the client to the server, or "pulled" by the server from a repository or other network service, including an online AC issuer.
6. ACは、クライアントによってサーバーに「プッシュ」されるか、リポジトリまたは他のネットワークサービス（オンラインAC発行者を含む）からサーバーによって「プル」されるように定義する必要があります。
ACs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability and limited special purpose requirements. In particular, the emphasis will be on supporting the use of attribute certificates for informal Internet electronic mail, IPsec, and WWW applications.
ACは、幅広い相互運用性の目標と、運用と保証の要件のより広い範囲をカバーする、幅広いアプリケーションと環境で使用できます。このドキュメントの目的は、幅広い相互運用性と限定された特別な目的の要件を必要とする汎用アプリケーションの共通ベースラインを確立することです。特に、非公式のインターネット電子メール、IPsec、およびWWWアプリケーションの属性証明書の使用をサポートすることに重点が置かれます。
This section presents a profile for ACs that will foster interoperability. This section also defines some private extensions for the Internet community.
このセクションでは、相互運用性を促進するACのプロファイルを示します。このセクションでは、インターネットコミュニティのプライベート拡張もいくつか定義しています。
While the ISO/IEC/ITU documents use the 1993 (or later) version of ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for PKCs [PKIXPROF]. The encoded certificates and extensions from either ASN.1 version are bit-wise identical.
ISO / IEC / ITUドキュメントは、1993年（またはそれ以降）のバージョンのASN.1を使用しますが、このドキュメントは、PKC [PKIXPROF]で行われていたように、1988 ASN.1構文を使用します。いずれかのASN.1バージョンからのエンコードされた証明書と拡張機能は、ビット単位で同一です。
Where maximum lengths for fields are specified, these lengths refer to the DER encoding and do not include the ASN.1 tag or length fields.
フィールドの最大長が指定されている場合、これらの長さはDERエンコードを参照し、ASN.1タグまたは長さフィールドは含まれません。
Conforming implementations MUST support the profile specified in this section.
適合する実装は、このセクションで指定されたプロファイルをサポートする必要があります。
X.509 contains the definition of an AC given below. All types that are not defined in this document can be found in [PKIXPROF].
X.509には、以下に示すACの定義が含まれています。このドキュメントで定義されていないすべてのタイプは、[PKIXPROF]にあります。
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the holder,
-- for example, an executable
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST NOT
-- be present in this profile
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
Although the Attribute syntax is defined in [PKIXPROF], we repeat the definition here for convenience.
属性構文は[PKIXPROF]で定義されていますが、便宜上ここで定義を繰り返します。
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
Implementers should note that the DER encoding (see [X.509-1988], [X.690]) of the SET OF values requires ordering of the encodings of the values. Though this issue arises with respect to distinguished names, and has to be handled by [PKIXPROF] implementations, it is much more significant in this context, since the inclusion of multiple values is much more common in ACs.
実装者は、SET OF値のDERエンコード（[X.509-1988]、[X.690]を参照）が値のエンコードの順序付けを必要とすることに注意する必要があります。この問題は識別名に関して発生し、[PKIXPROF]実装で処理する必要がありますが、ACでは複数の値を含めることが一般的であるため、このコンテキストでははるかに重要です。
GeneralName offers great flexibility. To achieve interoperability, in spite of this flexibility, this profile imposes constraints on the use of GeneralName.
GeneralNameは優れた柔軟性を提供します。相互運用性を実現するために、この柔軟性にもかかわらず、このプロファイルはGeneralNameの使用に制約を課します。
Conforming implementations MUST be able to support the dNSName, directoryName, uniformResourceIdentifier, and iPAddress options. This is compatible with the GeneralName requirements in [PKIXPROF] (mainly in Section 4.2.1.6). Implementations SHOULD also support the SRVName, as defined in [X509-SRV].
適合する実装は、dNSName、directoryName、uniformResourceIdentifier、およびiPAddressオプションをサポートできる必要があります。これは[PKIXPROF]（主にセクション4.2.1.6）のGeneralName要件と互換性があります。 [X509-SRV]で定義されているように、実装はSRVNameもサポートする必要があります（SHOULD）。
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options.
適合する実装では、x400Address、ediPartyName、またはregisteredIDオプションを使用してはなりません（MUST NOT）。
Conforming implementations MAY use the otherName option to convey name forms defined in Internet Standards. For example, Kerberos [KRB] format names can be encoded into the otherName, using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and the PrincipalName.
準拠する実装は、otherNameオプションを使用して、インターネット標準で定義されている名前の形式を伝えることができます。たとえば、Kerberos [KRB]形式の名前は、Kerberos 5プリンシパル名OID、およびレルムとPrincipalNameのシーケンスを使用して、otherNameにエンコードできます。
The version field MUST have the value of v2. That is, the version field is present in the DER encoding.
バージョンフィールドの値はv2でなければなりません。つまり、バージョンフィールドはDERエンコーディングに存在します。
Note: This version (v2) is not backwards compatible with the previous attribute certificate definition (v1) from the 1997 X.509 standard [X.509-1997], but is compatible with the v2 definition from X.509 (2000) [X.509-2000].
注：このバージョン（v2）は、1997 X.509標準[X.509-1997]の以前の属性証明書定義（v1）との下位互換性はありませんが、X.509（2000）のv2定義とは互換性があります[ X.509-2000]。
The Holder field is a SEQUENCE allowing three different (optional) syntaxes: baseCertificateID, entityName, and objectDigestInfo. Where only one option is present, the meaning of the Holder field is clear.
Holderフィールドは、baseCertificateID、entityName、objectDigestInfoの3つの異なる（オプションの）構文を許可するシーケンスです。オプションが1つしかない場合、[ホルダー]フィールドの意味は明確です。
However, where more than one option is used, there is a potential for confusion as to which option is "normative", which is a "hint", etc. Since the correct position is not clear from [X.509-2000], this specification RECOMMENDS that only one of the options be used in any given AC.
ただし、複数のオプションが使用されている場合、どのオプションが「規範的」であるか、つまり「ヒント」などであるかについて混乱が生じる可能性があります。正しい位置は[X.509-2000]から明確ではないため、この仕様では、任意のACで使用できるオプションは1つだけであることを推奨しています。
For any environment where the AC is passed in an authenticated message or session and where the authentication is based on the use of an X.509 PKC, the Holder field SHOULD use the baseCertificateID.
ACが認証されたメッセージまたはセッションで渡され、認証がX.509 PKCの使用に基づいている環境では、HolderフィールドはbaseCertificateIDを使用する必要があります（SHOULD）。
With the baseCertificateID option, the holder's PKC serialNumber and issuer MUST be identical to the AC Holder field. The PKC issuer MUST have a non-empty distinguished name that is to be present as the single value of the holder.baseCertificateID.issuer construct in the directoryName field. The AC holder.baseCertificateID.issuerUID field MUST only be used if the holder's PKC contains an issuerUniqueID field. If both the AC holder.baseCertificateID.issuerUID and the PKC issuerUniqueID fields are present, the same value MUST be present in both fields. Thus, the baseCertificateID is only usable with PKC profiles (like [PKIXPROF]) that mandate that the PKC issuer field contain a non-empty distinguished name value.
baseCertificateIDオプションを使用する場合、ホルダーのPKCシリアル番号と発行者はACホルダーフィールドと同一でなければなりません。 PKC発行者は、directoryNameフィールドのholder.baseCertificateID.issuerコンストラクトの単一の値として存在する空でない識別名を持っている必要があります。 AC Holder.baseCertificateID.issuerUIDフィールドは、ホルダーのPKCにissuerUniqueIDフィールドが含まれている場合にのみ使用する必要があります。 ACholder.baseCertificateID.issuerUIDとPKC issuerUniqueIDの両方のフィールドが存在する場合、同じ値が両方のフィールドに存在する必要があります。したがって、baseCertificateIDは、PKC発行者フィールドに空でない識別名の値を含めることを要求するPKCプロファイル（[PKIXPROF]など）でのみ使用できます。
Note: An empty distinguished name is a distinguished name where the SEQUENCE OF relative distinguished names is of zero length. In a DER encoding, this has the value '3000'H.
注：空の識別名は、相対識別名のシーケンスの長さがゼロの識別名です。 DERエンコードでは、これは値「3000」Hになります。
If the Holder field uses the entityName option and the underlying authentication is based on a PKC, the entityName MUST be the same as the PKC subject field or one of the values of the PKC subjectAltName field extension (if present). Note that [PKIXPROF] mandates that the subjectAltName extension be present if the PKC subject is an empty distinguished name. See the Security Considerations section, which mentions some name collision problems that may arise when using the entityName option.
HolderフィールドがentityNameオプションを使用し、基になる認証がPKCに基づいている場合、entityNameはPKCサブジェクトフィールドまたはPKC subjectAltNameフィールド拡張（存在する場合）の値の1つと同じである必要があります。 [PKIXPROF]では、PKCサブジェクトが空の識別名である場合、subjectAltName拡張が存在することが義務付けられていることに注意してください。 「セキュリティの考慮事項」セクションを参照してください。このセクションでは、entityNameオプションを使用するときに発生する可能性がある名前の衝突の問題について説明しています。
In any other case where the Holder field uses the entityName option, only one name SHOULD be present.
HolderフィールドがentityNameオプションを使用するその他の場合は、1つの名前のみが存在する必要があります（SHOULD）。
Implementations conforming to this profile are not required to support the use of the objectDigest field. However, Section 7.3 specifies how this optional feature MAY be used.
このプロファイルに準拠する実装は、objectDigestフィールドの使用をサポートする必要はありません。ただし、セクション7.3では、このオプション機能の使用方法を指定しています。
Any protocol conforming to this profile SHOULD specify which AC holder option is to be used and how this fits with the supported authentication schemes defined in that protocol.
このプロファイルに準拠するプロトコルは、使用するACホルダーオプションと、これがそのプロトコルで定義されているサポートされている認証方式にどのように適合するかを指定する必要があります（SHOULD）。
ACs conforming to this profile MUST use the v2Form choice, which MUST contain one and only one GeneralName in the issuerName, which MUST contain a non-empty distinguished name in the directoryName field. This means that all AC issuers MUST have non-empty distinguished names. ACs conforming to this profile MUST omit the baseCertificateID and objectDigestInfo fields.
このプロファイルに準拠するACは、v2Formの選択を使用する必要があります。これは、発行者名にGeneralNameを1つだけ含める必要があり、directoryNameフィールドに空でない識別名を含める必要があります。これは、すべてのAC発行者が空でない識別名を持っている必要があることを意味します。このプロファイルに準拠するACは、baseCertificateIDおよびobjectDigestInfoフィールドを省略しなければなりません（MUST）。
Part of the reason for the use of the v2Form containing only an issuerName is that it means that the AC issuer does not have to know which PKC the AC verifier will use for it (the AC issuer). Using the baseCertificateID field to reference the AC issuer would mean that the AC verifier would have to trust the PKC that the AC issuer chose (for itself) at AC creation time.
issuerNameのみを含むv2Formを使用する理由の一部は、AC発行者がACベリファイアが使用するPKC（AC発行者）を知る必要がないことを意味します。 baseCertificateIDフィールドを使用してAC発行者を参照することは、AC検証時に、AC作成者がAC作成時に（それ自体のために）選択したPKCを信頼する必要があることを意味します。
Contains the algorithm identifier used to validate the AC signature.
AC署名の検証に使用されるアルゴリズム識別子が含まれます。
This MUST be one of the signing algorithms defined in [PKIXALGS] or defined in any IETF-approved update to [PKIXALGS]. Conforming implementations MUST honor all MUST/SHOULD/MAY signing algorithm statements specified in [PKIXALGS] or IETF-approved updates to [PKIXALGS].
これは、[PKIXALGS]で定義されている、または[PKIXALGS]に対するIETF承認の更新で定義されている署名アルゴリズムの1つでなければなりません。準拠する実装は、[PKIXALGS]で指定されたすべてのMUST / SHOULD / MAY署名アルゴリズムステートメントまたはIETF承認の[PKIXALGS]への更新を尊重する必要があります。
For any conforming AC, the issuer/serialNumber pair MUST form a unique combination, even if ACs are very short-lived.
適合するACの場合、ACが非常に短命であっても、発行者/シリアル番号のペアは一意の組み合わせを形成する必要があります。
AC issuers MUST force the serialNumber to be a positive integer, that is, the sign bit in the DER encoding of the INTEGER value MUST be zero -- this can be done by adding a leading (leftmost) '00'H octet if necessary. This removes a potential ambiguity in mapping between a string of octets and an integer value.
AC発行者は、serialNumberを強制的に正の整数にする必要があります。つまり、INTEGER値のDERエンコードの符号ビットはゼロでなければなりません。これは、必要に応じて、先頭（左端）の '00'Hオクテットを追加することで実行できます。これにより、オクテットの文字列と整数値との間のマッピングにおける潜在的なあいまいさがなくなります。
Given the uniqueness and timing requirements above, serial numbers can be expected to contain long integers. AC users MUST be able to handle serialNumber values longer than 4 octets. Conformant ACs MUST NOT contain serialNumber values longer than 20 octets.
上記の一意性とタイミング要件を考慮すると、シリアル番号には長整数が含まれることが予想されます。 ACユーザーは、4オクテットよりも長いserialNumber値を処理できる必要があります。適合ACには、20オクテットよりも長いserialNumber値を含めてはなりません（MUST NOT）。
There is no requirement that the serial numbers used by any AC issuer follow any particular ordering. In particular, they need not be monotonically increasing with time. Each AC issuer MUST ensure that each AC that it issues contains a unique serial number.
AC発行者が使用するシリアル番号は、特定の順序に従う必要はありません。特に、時間とともに単調増加する必要はありません。各AC発行者は、発行する各ACに一意のシリアル番号が含まれていることを確認する必要があります。
The attrCertValidityPeriod (a.k.a. validity) field specifies the period for which the AC issuer certifies that the binding between the holder and the attributes fields will be valid.
attrCertValidityPeriod（別名有効性）フィールドは、AC発行者が保有者と属性フィールド間のバインディングが有効であることを認証する期間を指定します。
The generalized time type, GeneralizedTime, is a standard ASN.1 type for variable precision representation of time. The GeneralizedTime field can optionally include a representation of the time differential between the local time zone and Greenwich Mean Time.
汎用時間型GeneralizedTimeは、時間の可変精度表現用の標準ASN.1型です。 GeneralizedTimeフィールドには、オプションで、ローカルタイムゾーンとグリニッジ標準時との間の時差の表現を含めることができます。
For the purposes of this profile, GeneralizedTime values MUST be expressed in Coordinated universal time (UTC) (also known as Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
このプロファイルの目的のために、GeneralizedTime値は協定世界時（UTC）（グリニッジ標準時またはズールーとも呼ばれます）で表現する必要があり、秒数がゼロであっても秒を含める必要があります（つまり、時間はYYYYMMDDHHMMSSZです）。 。 GeneralizedTime値に小数秒を含めることはできません。
(Note: this is the same as specified in [PKIXPROF], Section 4.1.2.5.2.)
（注：これは[PKIXPROF]のセクション4.1.2.5.2で指定されているものと同じです。）
AC users MUST be able to handle an AC which, at the time of processing, has parts of its validity period or all its validity period in the past or in the future (a post-dated AC). This is valid for some applications, such as backup.
ACユーザーは、処理時に有効期間の一部または過去または将来のすべての有効期間を持つAC（日付指定後のAC）を処理できる必要があります。これは、バックアップなどの一部のアプリケーションに有効です。
The attributes field gives information about the AC holder. When the AC is used for authorization, this will often contain a set of privileges.
属性フィールドは、ACホルダーに関する情報を提供します。 ACが認証に使用される場合、これには多くの場合、一連の特権が含まれます。
The attributes field contains a SEQUENCE OF Attribute. Each Attribute contains the type of the attribute and a SET OF values. For a given AC, each AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That is, only one instance of each attribute can occur in a single AC, but each instance can be multi-valued.
属性フィールドには、属性のシーケンスが含まれています。各属性には、属性のタイプとSET OF値が含まれています。特定のACでは、シーケンス内の各AttributeType OBJECT IDENTIFIERは一意である必要があります。つまり、単一のACで発生できるのは各属性の1つのインスタンスのみですが、各インスタンスは複数の値を持つことができます。
AC users MUST be able to handle multiple values for all attribute types.
ACユーザーは、すべての属性タイプの複数の値を処理できる必要があります。
An AC MUST contain at least one attribute. That is, the SEQUENCE OF Attributes MUST NOT be of zero length.
ACは少なくとも1つの属性を含まなければなりません。つまり、SEQUENCE OF Attributeの長さがゼロであってはなりません。
Some standard attribute types are defined in Section 4.4.
いくつかの標準属性タイプはセクション4.4で定義されています。
This field MUST NOT be used unless it is also used in the AC issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] states that this field SHOULD NOT be used by conforming certification authorities (CAs), but that applications SHOULD be able to parse PKCs containing the field.
このフィールドは、AC発行者のPKCでも使用されている場合を除き、使用してはなりません。 [PKIXPROF]は、このフィールドは適合証明機関（CA）によって使用されるべきではない（SHOULD NOT）が、アプリケーションがフィールドを含むPKCを解析できる必要があることに注意してください。
The extensions field generally gives information about the AC as opposed to information about the AC holder.
拡張フィールドは、ACホルダーに関する情報ではなく、一般的にACに関する情報を提供します。
An AC that has no extensions conforms to the profile; however, Section 4.3 defines the extensions that MAY be used with this profile, and whether or not they may be marked critical. If any other critical extension is used, the AC does not conform to this profile. However, if any other non-critical extension is used, the AC does conform to this profile.
拡張子のないACはプロファイルに準拠します。ただし、セクション4.3では、このプロファイルで使用できる拡張機能と、それらが重要とマークされているかどうかを定義しています。他の重要な拡張機能が使用されている場合、ACはこのプロファイルに準拠していません。ただし、その他の重要でない拡張機能が使用されている場合、ACはこのプロファイルに準拠します。
The extensions defined for ACs provide methods for associating additional attributes with holders. This profile also allows communities to define private extensions to carry information unique to those communities. Each extension in an AC may be designated as critical or non-critical. An AC-using system MUST reject an AC if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. Section 4.3 presents recommended extensions used within Internet ACs and standard locations for information. Communities may elect to use additional extensions; however, caution should be exercised in adopting any critical extensions in ACs that might prevent use in a general context.
ACに対して定義された拡張は、追加の属性をホルダーに関連付けるためのメソッドを提供します。このプロファイルを使用すると、コミュニティはプライベート拡張を定義して、それらのコミュニティに固有の情報を伝達することもできます。 ACの各拡張は、クリティカルまたは非クリティカルとして指定できます。 ACを使用するシステムは、認識できない重要な拡張に遭遇した場合、ACを拒否する必要があります。ただし、重要でない拡張機能は、認識されない場合は無視されます。セクション4.3は、インターネットAC内で使用される推奨拡張機能と、情報の標準的な場所を示しています。コミュニティは、追加の拡張機能を使用することを選択できます。ただし、一般的なコンテキストでの使用を妨げる可能性があるACの重要な拡張を採用する場合は注意が必要です。
In some circumstances, it is required (e.g., by data protection/data privacy legislation) that audit trails not contain records that directly identify individuals. This circumstance may make the use of the AC Holder field unsuitable for use in audit trails.
状況によっては、監査証跡に個人を直接識別する記録が含まれていないことが必要です（データ保護/データプライバシー法など）。この状況では、ACホルダーフィールドを監査証跡での使用に適さないようにする場合があります。
To allow for such cases, an AC MAY contain an audit identity extension. Ideally, it SHOULD be infeasible to derive the AC holder's identity from the audit identity value without the cooperation of the AC issuer.
そのような場合を考慮に入れるために、ACには監査ID拡張が含まれる場合があります。理想的には、AC発行者の協力なしに監査ID値からAC所有者のIDを導出することは実行不可能であるべきです。
The value of the audit identity, along with the AC issuer/serial, SHOULD then be used for audit/logging purposes. If the value of the audit identity is suitably chosen, a server/service administrator can use audit trails to track the behavior of an AC holder without being able to identify the AC holder.
監査IDの値は、AC発行者/シリアルとともに、監査/ログ記録の目的で使用する必要があります（SHOULD）。監査IDの値が適切に選択されている場合、サーバー/サービス管理者は監査証跡を使用して、AC所有者を特定することなくAC所有者の動作を追跡できます。
The server/service administrator in combination with the AC issuer MUST be able to identify the AC holder in cases where misbehavior is detected. This means that the AC issuer MUST be able to determine the actual identity of the AC holder from the audit identity.
サーバー/サービス管理者は、AC発行者と連携して、不正行為が検出された場合にAC所有者を識別できる必要があります。これは、AC発行者が監査IDからAC所有者の実際のIDを判別できなければならないことを意味します。
Of course, auditing could be based on the AC issuer/serial pair; however, this method does not allow tracking of the same AC holder with multiple ACs. Thus, an audit identity is only useful if it lasts for longer than the typical AC lifetime. Auditing could also be based on the AC holder's PKC issuer/serial; however, this will often allow the server/service administrator to identify the AC holder.
もちろん、監査はAC発行者/シリアルのペアに基づくことができます。ただし、この方法では、同じACホルダーを複数のACで追跡することはできません。したがって、監査IDは、通常のAC寿命よりも長く続く場合にのみ役立ちます。監査は、AC所有者のPKC発行者/シリアルに基づくこともできます。ただし、これにより、サーバー/サービス管理者がAC所有者を識別できるようになります。
As the AC verifier might otherwise use the AC holder or some other identifying value for audit purposes, this extension MUST be critical when used.
AC検証者は、監査目的でACホルダーまたはその他の識別値を使用する可能性があるため、使用する場合、この拡張機能は重要です。
Protocols that use ACs will often expose the identity of the AC holder in the bits on-the-wire. In such cases, an opaque audit identity does not make use of the AC anonymous; it simply ensures that the ensuing audit trails do not contain identifying information.
ACを使用するプロトコルは、多くの場合、ACホルダーのIDをビットオンザワイヤーで公開します。そのような場合、不透明な監査IDはAC匿名を使用しません。その後の監査証跡に識別情報が含まれていないことを確認するだけです。
The value of an audit identity MUST be longer than zero octets. The value of an audit identity MUST NOT be longer than 20 octets.
監査IDの値は、0オクテットより長くなければなりません。監査IDの値は、20オクテットを超えてはなりません。
name id-pe-ac-auditIdentity OID { id-pe 4 } syntax OCTET STRING criticality MUST be TRUE
名前id-pe-ac-auditIdentity OID {id-pe 4}構文OCTET STRING重要度はTRUEでなければならない
To target an AC, the target information extension, imported from [X.509-2000], MAY be used to specify a number of servers/services. The intent is that the AC SHOULD only be usable at the specified servers/services. An (honest) AC verifier who is not amongst the named servers/services MUST reject the AC.
ACをターゲットにするには、[X.509-2000]からインポートされたターゲット情報拡張を使用して、サーバー/サービスの数を指定できます。その意図は、ACが指定されたサーバー/サービスでのみ使用可能であるべきである（SHOULD）ことです。指定されたサーバー/サービスに含まれていない（正直な）AC検証者は、ACを拒否する必要があります。
If this extension is not present, the AC is not targeted and may be accepted by any server.
この拡張が存在しない場合、ACはターゲットにならず、どのサーバーでも受け入れられる可能性があります。
In this profile, the targeting information simply consists of a list of named targets or groups.
このプロファイルでは、ターゲティング情報は、名前付きのターゲットまたはグループのリストで構成されています。
The following syntax is used to represent the targeting information:
次の構文は、ターゲティング情報を表すために使用されます。
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
The targetCert CHOICE within the Target structure is only present to allow future compatibility with [X.509-2000] and MUST NOT be used.
Target構造内のtargetCert CHOICEは、[X.509-2000]との将来の互換性を可能にするためにのみ存在し、使用してはなりません（MUST NOT）。
The targets check passes if the current server (recipient) is one of the targetName fields in the Targets SEQUENCE, or if the current server is a member of one of the targetGroup fields in the Targets SEQUENCE. In this case, the current server is said to "match" the targeting extension.
現在のサーバー（受信者）がTargets SEQUENCEのtargetNameフィールドの1つである場合、または現在のサーバーがTargets SEQUENCEのtargetGroupフィールドの1つのメンバーである場合、ターゲットチェックは合格です。この場合、現在のサーバーはターゲティング拡張機能と「一致」すると言われています。
How the membership of a target within a targetGroup is determined is not defined here. It is assumed that any given target "knows" the names of the targetGroups to which it belongs or can otherwise determine its membership. For example, the targetGroup specifies a DNS domain, and the AC verifier knows the DNS domain to which it belongs. For another example, the targetGroup specifies "PRINTERS", and the AC verifier knows whether or not it is a printer or print server.
targetGroup内のターゲットのメンバーシップがどのように決定されるかは、ここでは定義されていません。特定のターゲットは、それが属するtargetGroupsの名前を「知っている」か、そうでなければそのメンバーシップを決定できると想定されています。たとえば、targetGroupはDNSドメインを指定し、ACベリファイアはそれが属するDNSドメインを認識しています。別の例として、targetGroupは「PRINTERS」を指定し、AC検証者はそれがプリンターまたはプリントサーバーであるかどうかを認識しています。
Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF Targets". Conforming AC issuer implementations MUST only produce one "Targets" element. Conforming AC users MUST be able to accept a "SEQUENCE OF Targets". If more than one Targets element is found in an AC, the extension MUST be treated as if all Target elements had been found within one Targets element.
注：[X.509-2000]は、拡張構文を「ターゲットのシーケンス」として定義します。適合するAC発行者の実装は、「ターゲット」要素を1つだけ生成する必要があります。適合ACユーザーは、「ターゲットのシーケンス」を受け入れることができる必要があります。 ACで複数のTargets要素が見つかった場合、拡張機能は、1つのTargets要素内ですべてのTarget要素が見つかった場合と同様に処理する必要があります。
name id-ce-targetInformation OID { id-ce 55 } syntax SEQUENCE OF Targets criticality MUST be TRUE
name id-ce-targetInformation OID {id-ce 55} syntaxターゲットの重要度のシーケンスは真でなければなりません
The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY be used to assist the AC verifier in checking the signature of the AC. The [PKIXPROF] description should be read as if "CA" meant "AC issuer". As with PKCs, this extension SHOULD be included in ACs.
[PKIXPROF]にプロファイルされているように、authorityKeyIdentifier拡張は、ACの署名をチェックする際にACベリファイアを支援するために使用される場合があります。 [PKIXPROF]の説明は、「CA」が「AC発行者」を意味するかのように読む必要があります。 PKCと同様に、この拡張機能はACに含める必要があります（SHOULD）。
Note: An AC, where the issuer field used the baseCertificateID CHOICE, would not need an authorityKeyIdentifier extension, as it is explicitly linked to the key in the referred certificate. However, as this profile states (in Section 4.2.3), ACs MUST use the v2Form with issuerName CHOICE, this duplication does not arise.
注：発行者フィールドがbaseCertificateID CHOICEを使用したACは、参照された証明書のキーに明示的にリンクされているため、authorityKeyIdentifier拡張は必要ありません。ただし、このプロファイルに記載されているように（セクション4.2.3）、ACはissuerName CHOICEでv2Formを使用する必要があるため、この重複は発生しません。
name id-ce-authorityKeyIdentifier OID { id-ce 35 } syntax AuthorityKeyIdentifier criticality MUST be FALSE
名前id-ce-authorityKeyIdentifier OID {id-ce 35}構文AuthorityKeyIdentifier重要度はFALSEでなければなりません
The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by this profile since AC chains are not expected.
[PKIXPROF]で定義されているauthorityInfoAccess拡張は、ACの失効ステータスをチェックする際にAC検証者を支援するために使用されるかもしれません。 ACチェーンは想定されていないため、id-ad-caIssuers accessMethodのサポートはこのプロファイルではオプションです。
The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the Online Certificate Status Protocol (OCSP) defined in [OCSP]:
次のaccessMethodは、[OCSP]で定義されたオンライン証明書ステータスプロトコル（OCSP）を使用して、このACに失効ステータスチェックが提供されることを示すために使用されます。
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location.
accessLocationにはURIが含まれている必要があり、URIにはOCSPレスポンダの場所を指定するHTTP URL [HTTP-URL]が含まれている必要があります。 AC発行者は、もちろん、この場所にOCSPレスポンダを維持する必要があります。
name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE
名前id-ce-authorityInfoAccess OID {id-pe 1}構文AuthorityInfoAccessSyntax重要度はFALSEでなければなりません
The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. See Section 6 for details on revocation.
[PKIXPROF]でプロファイルされているcrlDistributionPoints拡張を使用して、AC検証者がACの失効ステータスをチェックするのを支援できます（MAY）。失効の詳細については、セクション6を参照してください。
If the crlDistributionPoints extension is present, then exactly one distribution point MUST be present. The crlDistributionPoints extension MUST use the DistributionPointName option, which MUST contain a fullName, which MUST contain a single name form. That name MUST contain either a distinguished name or a URI. The URI MUST be either an HTTP URL [HTTP-URL] or a Lightweight Directory Access Protocol (LDAP) URL [LDAP-URL].
crlDistributionPoints拡張が存在する場合、配布ポイントが1つだけ存在している必要があります。 crlDistributionPoints拡張は、DistributionPointNameオプションを使用する必要があります。これには、fullNameを含める必要があり、これには単一の名前形式を含める必要があります。その名前には、識別名またはURIを含める必要があります。 URIは、HTTP URL [HTTP-URL]またはライトウェイトディレクトリアクセスプロトコル（LDAP）URL [LDAP-URL]のいずれかでなければなりません。
name id-ce-cRLDistributionPoints OID { id-ce 31 } syntax CRLDistributionPoints criticality MUST be FALSE
名前id-ce-cRLDistributionPoints OID {id-ce 31}構文CRLDistributionPoints重要度はFALSEである必要があります
The noRevAvail extension, defined in [X.509-2000], allows an AC issuer to indicate that no revocation information will be made available for this AC.
[X.509-2000]で定義されているnoRevAvail拡張を使用すると、AC発行者は、このACで失効情報が利用可能にならないことを示すことができます。
This extension MUST be non-critical. An AC verifier that does not understand this extension might be able to find a revocation list from the AC issuer, but the revocation list will never include an entry for the AC.
この拡張は重要ではない必要があります。この拡張機能を理解しないAC検証者は、AC発行者から失効リストを見つけることができる場合がありますが、失効リストにはACのエントリは含まれません。
name id-ce-noRevAvail OID { id-ce 56 } syntax NULL (i.e., '0500'H is the DER encoding) criticality MUST be FALSE
name id-ce-noRevAvail OID {id-ce 56}構文NULL（つまり、 '0500'HはDERエンコーディングです）重要度はFALSEでなければなりません
Some of the attribute types defined below make use of the IetfAttrSyntax type, also defined below. The reasons for using this type are:
以下で定義されている属性タイプの一部は、同じく以下で定義されているIetfAttrSyntaxタイプを利用しています。このタイプを使用する理由は次のとおりです。
1. It allows a separation between the AC issuer and the attribute policy authority. This is useful for situations where a single policy authority (e.g., an organization) allocates attribute values, but where multiple AC issuers are deployed for performance or other reasons.
1. AC発行者と属性ポリシー機関を分離できます。これは、単一のポリシー機関（組織など）が属性値を割り当てるが、パフォーマンスやその他の理由で複数のAC発行者が配置されている場合に役立ちます。
2. The syntaxes allowed for values are restricted to OCTET STRING, OBJECT IDENTIFIER, and UTF8String, which significantly reduces the complexity associated with matching more general syntaxes. All multi-valued attributes using this syntax are restricted so that each value MUST use the same choice of value syntax. For example, AC issuers must not use one value with an oid and a second value with a string.
2. 値に使用できる構文は、OCTET STRING、OBJECT IDENTIFIER、およびUTF8Stringに制限されています。これにより、より一般的な構文の照合に関連する複雑さが大幅に軽減されます。この構文を使用するすべての多値属性は制限されているため、各値は同じ値の構文を使用する必要があります。たとえば、AC発行者は、oidで1つの値を使用し、文字列で2番目の値を使用してはなりません。
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
In the descriptions below, each attribute type is either tagged "Multiple Allowed" or "One Attribute value only; multiple values within the IetfAttrSyntax". This refers to the SET OF AttributeValues; the AttributeType still only occurs once, as specified in Section 4.2.7.
以下の説明では、各属性タイプに「複数許可」または「1つの属性値のみ、IetfAttrSyntax内の複数の値」というタグが付けられています。これは、SET OF AttributeValuesを参照します。セクション4.2.7で指定されているように、AttributeTypeは依然として1回だけ発生します。
The SvceAuthInfo attribute identifies the AC holder to the server/service by a name, and the attribute MAY include optional service specific authentication information. Typically, this will contain a username/password pair for a "legacy" application.
SvceAuthInfo属性は、サーバー/サービスに対するAC所有者を名前で識別し、属性にはオプションのサービス固有の認証情報を含めることができます（MAY）。通常、これには「レガシー」アプリケーションのユーザー名/パスワードのペアが含まれます。
This attribute provides information that can be presented by the AC verifier to be interpreted and authenticated by a separate application within the target system. Note that this is a different use to that intended for the accessIdentity attribute in 4.4.2 below.
この属性は、ACベリファイアによって提示され、ターゲットシステム内の別のアプリケーションによって解釈および認証される情報を提供します。これは、下記の4.4.2のaccessIdentity属性を意図したものとは異なる用途であることに注意してください。
This attribute type will typically be encrypted when the authInfo field contains sensitive information, such as a password (see Section 7.1).
この属性タイプは通常、authInfoフィールドにパスワードなどの機密情報が含まれている場合に暗号化されます（セクション7.1を参照）。
name id-aca-authenticationInfo OID { id-aca 1 } syntax SvceAuthInfo values Multiple allowed
名前id-aca-authenticationInfo OID {id-aca 1}構文SvceAuthInfo値複数使用可
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
The accessIdentity attribute identifies the AC holder to the server/service. For this attribute the authInfo field MUST NOT be present.
accessIdentity属性は、サーバー/サービスのAC所有者を識別します。この属性では、authInfoフィールドが存在してはなりません（MUST NOT）。
This attribute is intended to be used to provide information about the AC holder, that can be used by the AC verifier (or a larger system of which the AC verifier is a component) to authorize the actions of the AC holder within the AC verifier's system. Note that this is a different use to that intended for the svceAuthInfo attribute described in 4.4.1 above.
この属性は、AC所有者に関する情報を提供するために使用することを目的としており、AC検証者（またはAC検証者がコンポーネントであるより大きなシステム）が、AC検証者のシステム内のAC所有者のアクションを承認するために使用できます。 。これは、上記の4.4.1で説明したsvceAuthInfo属性の使用とは異なる用途であることに注意してください。
name id-aca-accessIdentity OID { id-aca 2 } syntax SvceAuthInfo values Multiple allowed
名前id-aca-accessIdentity OID {id-aca 2}構文SvceAuthInfo値複数使用可
The chargingIdentity attribute identifies the AC holder for charging purposes. In general, the charging identity will be different from other identities of the holder. For example, the holder's company may be charged for service.
chargeIdentity属性は、充電目的のACホルダーを識別します。一般に、課金IDは所有者の他のIDとは異なります。たとえば、所有者の会社がサービス料を請求される場合があります。
name id-aca-chargingIdentity OID { id-aca 3 } syntax IetfAttrSyntax values One Attribute value only; multiple values within the IetfAttrSyntax
name id-aca-chargingIdentity OID {id-aca 3}構文IetfAttrSyntax値1つの属性値のみ。 IetfAttrSyntax内の複数の値
The group attribute carries information about group memberships of the AC holder.
group属性には、ACホルダーのグループメンバーシップに関する情報が含まれます。
name id-aca-group OID { id-aca 4 } syntax IetfAttrSyntax values One Attribute value only; multiple values within the IetfAttrSyntax
name id-aca-group OID {id-aca 4}構文IetfAttrSyntax値1つの属性値のみ。 IetfAttrSyntax内の複数の値
The role attribute, specified in [X.509-2000], carries information about role allocations of the AC holder.
[X.509-2000]で指定されているロール属性は、ACホルダーのロール割り当てに関する情報を保持します。
The syntax used for this attribute is:
この属性に使用される構文は次のとおりです。
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
The roleAuthority field MAY be used to specify the issuing authority for the role specification certificate. There is no requirement that a role specification certificate necessarily exists for the roleAuthority. This differs from [X.500-2000], where the roleAuthority field is assumed to name the issuer of a role specification certificate. For example, to distinguish the administrator role as defined by "Baltimore" from that defined by "SPYRUS", one could put the value "urn:administrator" in the roleName field and the value "Baltimore" or "SPYRUS" in the roleAuthority field.
roleAuthorityフィールドは、ロール仕様証明書の発行機関を指定するために使用される場合があります。 roleAuthorityには、必ずロール仕様証明書が存在する必要はありません。これは、[X.500-2000]とは異なります。この場合、roleAuthorityフィールドは、ロール仕様証明書の発行者を指定すると想定されています。たとえば、「Baltimore」で定義された管理者の役割を「SPYRUS」で定義された役割と区別するには、roleNameフィールドに値「urn：administrator」を入力し、roleAuthorityフィールドに値「Baltimore」または「SPYRUS」を入力します。 。
The roleName field MUST be present, and roleName MUST use the uniformResourceIdentifier CHOICE of the GeneralName.
roleNameフィールドが存在する必要があり、roleNameはGeneralNameのuniformResourceIdentifier CHOICEを使用する必要があります。
name id-at-role OID { id-at 72 } syntax RoleSyntax values Multiple allowed
name id-at-role OID {id-at 72}構文RoleSyntax値複数指定可能
The clearance attribute, specified in [X.501-1993], carries clearance (associated with security labeling) information about the AC holder.
[X.501-1993]で指定されている認可上限属性は、ACホルダーに関する認可（セキュリティラベル付けに関連）情報を保持します。
The policyId field is used to identify the security policy to which the clearance relates. The policyId indicates the semantics of the classList and securityCategories fields.
policyIdフィールドは、認可上限が関連するセキュリティポリシーを識別するために使用されます。 policyIdは、classListおよびsecurityCategoriesフィールドのセマンティクスを示します。
This specification includes the classList field exactly as it is specified in [X.501-1993]. Additional security classification values, and their position in the classification hierarchy, may be defined by a security policy as a local matter or by bilateral agreement. The basic security classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, and top-secret.
この仕様には、[X.501-1993]で指定されているとおりのclassListフィールドが含まれています。追加のセキュリティ分類値、および分類階層におけるそれらの位置は、ローカルポリシーとしてのセキュリティポリシーによって、または二国間合意によって定義される場合があります。基本的なセキュリティ分類階層は、昇順で、マークなし、分類なし、制限付き、機密、秘密、および最高機密です。
An organization can develop its own security policy that defines security classification values and their meanings. However, the BIT STRING positions 0 through 5 are reserved for the basic security classification hierarchy.
組織は、セキュリティ分類値とその意味を定義する独自のセキュリティポリシーを開発できます。ただし、BIT STRINGの位置0〜5は、基本的なセキュリティ分類階層用に予約されています。
If present, the SecurityCategory field provides further authorization information. The security policy identified by the policyId field indicates the syntaxes that are allowed to be present in the securityCategories SET. An OBJECT IDENTIFIER identifies each of the allowed syntaxes. When one of these syntaxes is present in the securityCategories SET, the OBJECT IDENTIFIER associated with that syntax is carried in the SecurityCategory.type field.
存在する場合、SecurityCategoryフィールドは追加の認証情報を提供します。 policyIdフィールドで識別されるセキュリティポリシーは、securityCategories SETに存在できる構文を示します。 OBJECT IDENTIFIERは、許可されている各構文を識別します。これらの構文のいずれかがsecurityCategories SETに存在する場合、その構文に関連付けられたOBJECT IDENTIFIERがSecurityCategory.typeフィールドに含まれます。
The object identifier for the clearance attribute from [RFC3281] is:
[RFC3281]の認可上限属性のオブジェクト識別子は次のとおりです。
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
clearance (55) }
The associated syntax was originally (and erroneously) defined in [RFC3281] as:
関連する構文は、元々（そして誤って）[RFC3281]で次のように定義されていました。
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
But, it was later corrected (to restore conformance with [X.509-1997]) to:
しかし、（[X.509-1997]への準拠を復元するために）後で修正されました。
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
The object identifier for the clearance attribute from [X.509-1997] is:
[X.509-1997]の認可上限属性のオブジェクト識別子は次のとおりです。
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
The associated syntax is as follows:
関連する構文は次のとおりです。
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Implementations MUST support the clearance attribute as defined in [X.501-1997]. Implementations SHOULD support decoding the clearance syntax from [RFC3281] and the errata report against it (see Appendix C). Implementations MUST NOT output the clearance attribute as defined in [RFC3281].
実装は、[X.501-1997]で定義されている認可上限属性をサポートする必要があります。実装は、[RFC3281]からの認可上限構文のデコードと、それに対する正誤表レポートをサポートする必要があります（付録Cを参照）。 [RFC3281]で定義されているように、実装は認可上限属性を出力してはならない（MUST NOT）。
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
-- Note that in [RFC3281], the SecurityCategory syntax was as
-- follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encodings.
-- This is the same as the original syntax, which was defined
-- using the MACRO construct, as follows:
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type
-- }
--
-- SECURITY-CATEGORY MACRO ::=
-- BEGIN
-- TYPE NOTATION ::= type | empty
-- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-- END
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) attribute-type (4)
clearance (55) }
syntax Clearance -- imported from [X.501-1997]
values Multiple allowed
The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage extension in the PKC MUST NOT explicitly indicate that the AC issuer's public key cannot be used to validate a digital signature. In order to avoid confusion regarding serial numbers and revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a basicConstraints extension with the cA boolean set to TRUE.
AC発行者のPKCは[PKIXPROF]に準拠する必要があり、PKCのkeyUsage拡張機能は、AC発行者の公開鍵を使用してデジタル署名を検証できないことを明示的に示してはなりません。シリアル番号と失効に関する混乱を避けるために、AC発行者はPKC発行者であってはなりません。つまり、AC発行者がCAになることはできません。したがって、AC発行者のPKCには、cAブール値がTRUEに設定されたbasicConstraints拡張があってはなりません。
This section describes a basic set of rules that all valid ACs MUST satisfy. Some additional checks are also described, which AC verifiers MAY choose to implement.
このセクションでは、すべての有効なACが満たさなければならない基本的なルールのセットについて説明します。いくつかの追加のチェックについても説明します。AC検証者は、実装することを選択できます。
To be valid, an AC MUST satisfy all of the following:
有効であるためには、ACは以下のすべてを満たす必要があります。
1. Where the holder uses a PKC to authenticate to the AC verifier, the AC holder's PKC MUST be found, and the entire certification path of that PKC MUST be verified in accordance with [PKIXPROF]. As noted in the Security Considerations section, if some other authentication scheme is used, AC verifiers need to be very careful mapping the identities (authenticated identity, holder field) involved.
1. 所有者がPKCを使用してAC検証者に認証する場合、AC所有者のPKCを見つけなければならず、そのPKCの認証パス全体を[PKIXPROF]に従って検証する必要があります。 「セキュリティに関する考慮事項」のセクションで説明したように、他の認証スキームを使用する場合、AC検証者は、含まれるID（認証済みID、ホルダーフィールド）を非常に注意深くマッピングする必要があります。
2. The AC signature must be cryptographically correct, and the AC issuer's entire PKC certification path MUST be verified in accordance with [PKIXPROF].
2. AC署名は暗号的に正しい必要があり、AC発行者のPKC証明書パス全体を[PKIXPROF]に従って検証する必要があります。
3. The AC issuer's PKC MUST also conform to the profile specified in Section 4.5 above.
3. AC発行者のPKCは、上記のセクション4.5で指定されたプロファイルにも準拠する必要があります。
4. The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise).
4. AC発行者は、（構成などによって）AC発行者として直接信頼されている必要があります。
5. The time for which the AC is being evaluated MUST be within the AC validity. If the evaluation time is equal to either notBeforeTime or notAfterTime, then the AC is timely and this check succeeds. Note that in some applications, the evaluation time MAY not be the same as the current time.
5. ACが評価されている時間は、ACの有効期間内でなければなりません。評価時間がnotBeforeTimeまたはnotAfterTimeのいずれかに等しい場合、ACはタイムリーであり、このチェックは成功します。一部のアプリケーションでは、評価時間は現在の時間と同じにならない場合があります。
6. The AC targeting check MUST pass as specified in Section 4.3.2.
6. ACターゲッティングチェックは、セクション4.3.2で指定されているとおりにパスする必要があります。
7. If the AC contains an unsupported critical extension, the AC MUST be rejected.
7. ACにサポートされていない重要な拡張が含まれている場合、ACは拒否される必要があります。
Support for an extension in this context means:
このコンテキストでの拡張機能のサポートは、次のことを意味します。
1. The AC verifier MUST be able to parse the extension value.
1. ACベリファイアは拡張値を解析できなければなりません（MUST）。
2. Where the extension value causes the AC to be rejected, the AC verifier MUST reject the AC.
2. 拡張値によってACが拒否される場合、AC検証者はACを拒否する必要があります。
Additional Checks:
追加のチェック：
1. The AC MAY be rejected on the basis of further AC verifier configuration. For example, an AC verifier may be configured to reject ACs that contain or lack certain attributes.
1. ACは、その後のACベリファイア構成に基づいて拒否される場合があります。たとえば、特定の属性を含むまたは欠くACを拒否するようにACベリファイアを構成できます。
2. If the AC verifier provides an interface that allows applications to query the contents of the AC, then the AC verifier MAY filter the attributes from the AC on the basis of configured information. For example, an AC verifier might be configured not to return certain attributes to certain servers.
2. ACベリファイアが、アプリケーションがACのコンテンツをクエリできるようにするインターフェイスを提供する場合、ACベリファイアは、構成された情報に基づいてACから属性をフィルタリングできます（MAY）。たとえば、特定の属性を特定のサーバーに返さないようにACベリファイアが構成されている場合があります。
In many environments, the validity period of an AC is less than the time required to issue and distribute revocation information. Therefore, short-lived ACs typically do not require revocation support. However, long-lived ACs and environments where ACs enable high value transactions MAY require revocation support.
多くの環境では、ACの有効期間は、失効情報の発行と配布に必要な時間よりも短くなります。したがって、有効期間が短いACは通常、失効サポートを必要としません。ただし、長期間有効なACおよびACが高価値のトランザクションを可能にする環境では、失効サポートが必要になる場合があります。
Two revocation schemes are defined, and the AC issuer should elect the one that is best suited to the environment in which the AC will be employed.
2つの失効スキームが定義されており、AC発行者は、ACが採用される環境に最も適したものを選択する必要があります。
"Never revoke" scheme:
「取り消さない」スキーム：
ACs may be marked so that the relying party understands that no revocation status information will be made available. The noRevAvail extension is defined in Section 4.3.6, and the noRevAvail extension MUST be present in the AC to indicate use of this scheme.
証明書に失効ステータス情報が提供されないことを証明書利用者が理解できるように、ACにマークを付けることができます。 noRevAvail拡張はセクション4.3.6で定義されており、noRevAvail拡張はこのスキームの使用を示すためにACに存在しなければなりません（MUST）。
Where no noRevAvail is present, the AC issuer is implicitly stating that revocation status checks are supported, and some revocation method MUST be provided to allow AC verifiers to establish the revocation status of the AC.
noRevAvailが存在しない場合、AC発行者は、失効ステータスチェックがサポートされていることを暗黙的に示し、AC検証者がACの失効ステータスを確立できるように、いくつかの失効メソッドを提供する必要があります。
"Pointer in AC" scheme:
「ACのポインター」スキーム：
ACs may "point" to sources of revocation status information, using either an authorityInfoAccess extension or a crlDistributionPoints extension within the AC.
ACは、AuthorizationInfoAccess拡張またはAC内のcrlDistributionPoints拡張を使用して、失効ステータス情報のソースを「ポイント」できます。
For AC users, the "never revoke" scheme MUST be supported, and the "pointer in AC" scheme SHOULD be supported. If only the "never revoke" scheme is supported, then all ACs that do not contain a noRevAvail extension, MUST be rejected.
ACユーザーの場合、「取り消し禁止」スキームをサポートする必要があり、「ACのポインター」スキームをサポートする必要があります（SHOULD）。 「取り消し禁止」スキームのみがサポートされている場合、noRevAvail拡張を含まないすべてのACは拒否されなければならない（MUST）。
For AC issuers, the "never revoke" scheme MUST be supported. If all ACs that will ever be issued by that AC issuer contain a noRevAvail extension, the "pointer in AC" scheme need not be supported. If any AC can be issued that does not contain the noRevAvail extension, the "pointer in AC" scheme MUST be supported.
AC発行者の場合、「取り消し禁止」スキームをサポートする必要があります。そのAC発行者によって発行されるすべてのACにnoRevAvail拡張が含まれている場合、「ACのポインター」スキームをサポートする必要はありません。 noRevAvail拡張を含まないACを発行できる場合、「ACのポインター」スキームをサポートする必要があります。
An AC MUST NOT contain both a noRevAvail extension and a "pointer in AC".
ACには、noRevAvail拡張と「AC内のポインター」の両方を含めることはできません。
An AC verifier MAY use any source for AC revocation status information.
AC検証者は、AC失効ステータス情報に任意のソースを使用してもよい（MAY）。
This section specifies features that MAY be implemented. Conformance to this profile does NOT require support for these features; however, if these features are offered, they MUST be offered as described below.
このセクションでは、実装できる機能を指定します。このプロファイルへの準拠は、これらの機能のサポートを必要としません。ただし、これらの機能を提供する場合は、以下で説明するように提供する必要があります。
AC attributes MAY need to be encrypted if the AC is carried in the clear within an application protocol or the AC contains sensitive information (e.g., username/password).
ACがアプリケーションプロトコル内で平文で送信される場合、またはACに機密情報（ユーザー名/パスワードなど）が含まれる場合、AC属性を暗号化する必要がある場合があります。
When a set of attributes is to be encrypted within an AC, the Cryptographic Message Syntax, EnvelopedData structure [CMS] is used to carry the ciphertext and associated per-recipient keying information.
一連の属性をAC内で暗号化する場合、暗号化メッセージの構文、EnvelopedData構造[CMS]を使用して、暗号文と関連する受信者ごとのキー情報を伝達します。
This type of attribute encryption is targeted. Before the AC is signed, the attributes are encrypted for a set of predetermined recipients.
このタイプの属性暗号化が対象です。 ACが署名される前に、一連の事前定義された受信者の属性が暗号化されます。
Within EnvelopedData, the encapsulatedContentInfo identifies the content type carried within the ciphertext. In this case, the contentType field of encapsulatedContentInfo MUST contain id-ct-attrCertEncAttrs, which has the following value:
EnvelopedData内で、capsulatedContentInfoは暗号文内で運ばれるコンテンツタイプを識別します。この場合、capsulatedContentInfoのcontentTypeフィールドには、次の値を持つid-ct-attrCertEncAttrsが含まれている必要があります。
attrCertEncAttrs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 14 }
The ciphertext is included in the AC as the value of an encAttrs attribute. Only one encAttrs attribute can be present in an AC; however, the encAttrs attribute MAY be multi-valued, and each of its values will contain an independent EnvelopedData.
暗号文は、encAttrs属性の値としてACに含まれています。 ACに存在できるencAttrs属性は1つだけです。ただし、encAttrs属性は複数値にすることができ（MAY）、その各値には独立したEnvelopedDataが含まれます。
Each value can contain a set of attributes (each possibly a multi-valued attribute) encrypted for a set of predetermined recipients.
各値には、事前に決定された受信者のセットに対して暗号化された属性のセット（それぞれ多値属性）を含めることができます。
The cleartext that is encrypted has the type:
暗号化されるクリアテキストには、次のタイプがあります。
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
The DER encoding of the ACClearAttrs structure is used as the encryptedContent field of the EnvelopedData. The DER encoding MUST be embedded in an OCTET STRING.
ACClearAttrs構造のDERエンコードは、EnvelopedDataのencryptedContentフィールドとして使用されます。 DERエンコードは、OCTET STRINGに埋め込まれている必要があります。
The acIssuer and acSerial fields are present to prevent ciphertext stealing. When an AC verifier has successfully decrypted an encrypted attribute, it MUST then check that the AC issuer and serialNumber fields contain the same values. This prevents a malicious AC issuer from copying ciphertext from another AC (without knowing its corresponding plaintext).
acIssuerおよびacSerialフィールドは、暗号文の盗用を防ぐために存在します。 ACベリファイアが暗号化された属性を正常に復号化したら、ACの発行者とserialNumberフィールドに同じ値が含まれていることを確認する必要があります。これにより、悪意のあるAC発行者が別のACから暗号文を（対応する平文を知らなくても）コピーすることを防ぎます。
The procedure for an AC issuer when encrypting attributes is illustrated by the following (any other procedure that gives the same result MAY be used):
属性を暗号化するときのAC発行者の手順を以下に示します（同じ結果が得られる他の手順を使用できます）。
1. Identify the sets of attributes that are to be encrypted for each set of recipients.
1. 受信者のセットごとに暗号化される属性のセットを識別します。
2. For each attribute set that is to be encrypted:
2. 暗号化する属性セットごとに：
2.1. Create an EnvelopedData structure for the data for this set of recipients.
2.1. この受信者セットのデータのEnvelopedData構造を作成します。
2.2. Encode the ContentInfo containing the EnvelopedData as a value of the encAttrs attribute.
2.2. EnvelopedDataを含むContentInfoをencAttrs属性の値としてエンコードします。
2.3. Ensure the cleartext attributes are not present in the to-be-signed AC.
2.3. クリアテキスト属性が署名されるACに存在しないことを確認してください。
3. Add the encAttrs (with its multiple values) to the AC.
3. encAttrs（および複数の値）をACに追加します。
Note that there may be more than one attribute of the same type (the same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain the same attribute type both in clear and in encrypted form (and indeed several times if the different recipients are associated with more than one EnvelopedData). For example, an AC could contain a cleartext clearance attribute saying the holder is cleared to SECRET, and, in addition, an encrypted clearance attribute whose value is some higher clearance that's not allowed to be known everywhere. One approach implementers may choose, would be to merge attribute values following decryption in order to re-establish the "once only" constraint.
復号化後、同じタイプ（同じOBJECT IDENTIFIER）の属性が複数存在する場合があることに注意してください。つまり、ACには同じ属性タイプが平文と暗号化された形式の両方で含まれる場合があります（実際、異なる受信者が複数のEnvelopedDataに関連付けられている場合は数回）。たとえば、ACには、所有者がSECRETにクリアされたことを示すクリアテキストクリアランス属性と、さらに、どこでも知られていることを許可されていない、より高いクリアランスである暗号化されたクリアランス属性を含めることができます。実装者が選択できる1つのアプローチは、「一度だけ」の制約を再確立するために、復号化の後に属性値をマージすることです。
name id-aca-encAttrs OID { id-aca 6} syntax ContentInfo values Multiple Allowed
名前id-aca-encAttrs OID {id-aca 6}構文ContentInfo値複数許可
If an AC contains attributes apparently encrypted for the AC verifier, then the decryption process failure MUST cause the AC to be rejected.
ACにACベリファイア用に明らかに暗号化された属性が含まれている場合、復号化プロセスの失敗によりACが拒否される必要があります。
When a server acts as a client for another server on behalf of the AC holder, the server MAY need to proxy an AC. Such proxying MAY have to be done under the AC issuer's control, so that not every AC is proxiable and so that a given proxiable AC can be proxied in a targeted fashion. Support for chains of proxies (with more than one intermediate server) MAY also be required. Note that this does not involve a chain of ACs.
サーバーがAC所有者の代わりに別のサーバーのクライアントとして機能する場合、サーバーはACをプロキシする必要があります。このようなプロキシは、AC発行者の制御下で実行する必要があるため、すべてのACがプロキシ可能であるとは限らず、特定のプロキシ可能ACをターゲットにした方法でプロキシできるようにする必要があります。プロキシのチェーン（複数の中間サーバーを持つ）のサポートも必要になる場合があります。これにはACのチェーンは含まれないことに注意してください。
In order to meet this requirement, we define another extension, ProxyInfo, similar to the targeting extension.
この要件を満たすために、ターゲティング拡張と同様に、別の拡張ProxyInfoを定義します。
When this extension is present, the AC verifier MUST check that the entity from which the AC was received was allowed to send it and that the AC is allowed to be used by this verifier.
この拡張機能が存在する場合、AC検証者は、ACの受信元のエンティティが送信を許可されていること、およびACがこの検証者による使用を許可されていることを確認する必要があります。
The proxying information is a list in which each item is a list of targeting information. If the verifier and the sender of the AC are both named in the same proxy list, the AC can then be accepted (the exact rule is given below).
プロキシ情報は、各項目がターゲティング情報のリストであるリストです。検証者とACの送信者の両方が同じプロキシリストで名前が付けられている場合、ACを受け入れることができます（正確なルールは以下のとおりです）。
The effect is that the AC holder can send the AC to any valid target, which can then only proxy to targets that are in one of the same proxy lists as itself.
その結果、AC所有者はACを任意の有効なターゲットに送信でき、それはそれ自体と同じプロキシリストの1つにあるターゲットにのみプロキシできます。
The following data structure is used to represent the targeting/proxying information:
次のデータ構造は、ターゲティング/プロキシ情報を表すために使用されます。
ProxyInfo ::= SEQUENCE OF Targets
Targets is explained in Section 4.3.2. As in the case of targeting, the targetCert CHOICE MUST NOT be used.
ターゲットについては、セクション4.3.2で説明します。ターゲティングの場合と同様に、targetCert CHOICEを使用してはなりません。
A proxy check succeeds if either one of the conditions below is met:
以下のいずれかの条件が満たされると、プロキシチェックは成功します。
1. The identity of the sender, as established by the underlying authentication service, matches the Holder field of the AC, and the current server "matches" any one of the proxy sets. Recall that "matches" is as defined Section 4.3.2.
1. 基礎となる認証サービスによって確立された送信者のIDは、ACのHolderフィールドと一致し、現在のサーバーはいずれかのプロキシセットと「一致」します。 「一致」はセクション4.3.2で定義されているとおりであることを思い出してください。
2. The identity of the sender, as established by the underlying authentication service, "matches" one of the proxy sets (call it set "A"), and the current server is one of the targetName fields in the set "A", or the current server is a member of one of the targetGroup fields in set "A".
2. 基礎となる認証サービスによって確立された送信者のIDは、プロキシセットの1つに「一致」し（セット "A"と呼びます）、現在のサーバーは、セット "A"のtargetNameフィールドの1つです。現在のサーバーは、セット "A"のtargetGroupフィールドの1つのメンバーです。
When an AC is proxied more than once, a number of targets will be on the path from the original client, which is normally, but not always, the AC holder. In such cases, prevention of AC "stealing" requires that the AC verifier MUST check that all targets on the path are members of the same proxy set. It is the responsibility of the AC-using protocol to ensure that a trustworthy list of targets on the path is available to the AC verifier.
ACが複数回プロキシされる場合、多数のターゲットが元のクライアントからのパス上にあります。これは、常にではありませんが、ACホルダーです。このような場合、ACの「盗用」を防ぐには、パス上のすべてのターゲットが同じプロキシセットのメンバーであることをAC検証者が確認する必要があります。パス上のターゲットの信頼できるリストがACベリファイアで利用できるようにするのは、ACを使用するプロトコルの責任です。
name id-pe-ac-proxying OID { id-pe 10 } syntax ProxyInfo criticality MUST be TRUE
名前id-pe-ac-proxying OID {id-pe 10}構文ProxyInfo重要度はTRUEである必要があります
In some environments, it may be required that the AC is not linked either to an identity (via entityName) or to a PKC (via baseCertificateID). The objectDigestInfo CHOICE in the Holder field allows support for this requirement.
一部の環境では、ACが（entityNameを介して）IDに、または（baseCertificateIDを介して）PKCにリンクされていないことが必要な場合があります。 HolderフィールドのobjectDigestInfo CHOICEでは、この要件をサポートできます。
If the holder is identified with the objectDigestInfo field, then the AC version field MUST contain v2 (the integer 1).
ホルダーがobjectDigestInfoフィールドで識別される場合、ACバージョンフィールドにはv2（整数1）が含まれている必要があります。
The idea is to link the AC to an object by placing a hash of that object into the Holder field of the AC. For example, this allows production of ACs that are linked to public keys rather than names. It also allows production of ACs that contain privileges associated with an executable object such as a Java class. However, this profile only specifies how to use a hash over a public key or PKC. That is, conformant ACs MUST NOT use the otherObjectTypes value for the digestedObjectType.
アイデアは、オブジェクトのハッシュをACのホルダーフィールドに配置することによって、ACをオブジェクトにリンクすることです。たとえば、これにより、名前ではなく公開鍵にリンクされているACを生成できます。また、Javaクラスなどの実行可能オブジェクトに関連付けられた特権を含むACを生成することもできます。ただし、このプロファイルは、公開鍵またはPKCでハッシュを使用する方法のみを指定します。つまり、適合ACは、digestedObjectTypeにotherObjectTypes値を使用してはなりません（MUST NOT）。
To link an AC to a public key, the hash must be calculated over the representation of that public key, which would be present in a PKC, specifically, the input for the hash algorithm MUST be the DER encoding of a SubjectPublicKeyInfo representation of the key.
ACを公開鍵にリンクするには、PKCに存在するその公開鍵の表現に対してハッシュを計算する必要があります。具体的には、ハッシュアルゴリズムの入力は、鍵のSubjectPublicKeyInfo表現のDERエンコードである必要があります。 。
Note: this includes the AlgorithmIdentifier as well as the BIT STRING. The rules given in [PKIXALGS] for encoding keys MUST be followed. In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present.
注：これには、AlgorithmIdentifierとBIT STRINGが含まれます。 [PKIXALGS]で指定されたキーのエンコードに関する規則に従う必要があります。この場合、digestedObjectTypeはpublicKeyでなければならず、otherObjectTypeIDフィールドは存在してはなりません（MUST NOT）。
Note that if the public key value used as input to the hash function has been extracted from a PKC, it is possible that the SubjectPublicKeyInfo from that PKC is NOT the value that should be hashed. This can occur if Digital Signature Algorithm (DSA) Dss-parms are inherited as described in Section 2.3.2 of [PKIXALGS]. The correct input for hashing in this context will include the value of the parameters inherited from the CA's PKC, and thus may differ from the SubjectPublicKeyInfo present in the PKC.
ハッシュ関数への入力として使用される公開鍵の値がPKCから抽出された場合、そのPKCからのSubjectPublicKeyInfoがハッシュされるべき値ではない可能性があることに注意してください。これは、[PKIXALGS]のセクション2.3.2で説明されているように、デジタル署名アルゴリズム（DSA）Dss-parmsが継承される場合に発生する可能性があります。このコンテキストでのハッシュの正しい入力には、CAのPKCから継承されたパラメーターの値が含まれるため、PKCに存在するSubjectPublicKeyInfoとは異なる場合があります。
Implementations that support this feature MUST be able to handle the representations of public keys for the algorithms specified in Section 2.3 of [PKIXALGS].
この機能をサポートする実装は、[PKIXALGS]のセクション2.3で指定されたアルゴリズムの公開鍵の表現を処理できなければなりません（MUST）。
In order to link an AC to a PKC via a digest, the digest MUST be calculated over the DER encoding of the entire PKC, including the signature value. In this case, the digestedObjectType MUST be publicKeyCert and the otherObjectTypeID field MUST NOT be present.
ACをダイジェストを介してPKCにリンクするには、ダイジェストを、署名値を含むPKC全体のDERエンコーディングで計算する必要があります。この場合、digestedObjectTypeはpublicKeyCertでなければならず、otherObjectTypeIDフィールドは存在してはなりません（MUST NOT）。
During AC validation, a relying party has to answer the question: is this AC issuer trusted to issue ACs containing this attribute? The AAControls PKC extension MAY be used to help answer the question. The AAControls extension is intended to be used in CA and AC issuer PKCs.
AC検証中、証明書利用者は質問に答える必要があります。このAC発行者は、この属性を含むACを発行すると信頼されていますか？ AAControls PKC拡張機能は、質問への回答を助けるために使用される場合があります。 AAControls拡張機能は、CAおよびAC発行者のPKCで使用することを目的としています。
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
The AAControls extension is used as follows:
AAControls拡張機能は次のように使用されます。
The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. It restricts the allowed distance between the AA CA (a CA directly trusted to include AAControls in its PKCs), and the AC issuer.
pathLenConstraintが存在する場合、[PKIXPROF]のように解釈されます。これは、AA CA（そのPKCにAAControlsを含めることが直接信頼されているCA）とAC発行者の間の許容距離を制限します。
The permittedAttrs field specifies a list of attribute types that any AC issuer below this AA CA is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly allowed.
allowedAttrsフィールドは、このAA CAの下のすべてのAC発行者がACに含めることが許可されている属性タイプのリストを指定します。このフィールドが存在しない場合は、明示的に許可されている属性タイプがないことを意味します。
The excludedAttrs field specifies a list of attribute types that no AC issuer below this AA CA is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly disallowed.
excludeAttrsフィールドは、このAA CAの下のAC発行者がACに含めることが許可されない属性タイプのリストを指定します。このフィールドが存在しない場合は、明示的に禁止されている属性タイプがないことを意味します。
The permitUnSpecified field specifies how to handle attribute types that are not present in either the permittedAttrs or excludedAttrs fields. TRUE (the default) means that any unspecified attribute type is allowed in ACs; FALSE means that no unspecified attribute type is allowed.
permitUnSpecifiedフィールドは、allowedAttrsフィールドまたはexcludedAttrsフィールドのいずれにも存在しない属性タイプの処理方法を指定します。 TRUE（デフォルト）は、指定されていない属性タイプがACで許可されることを意味します。 FALSEは、未指定の属性タイプが許可されないことを意味します。
When AAControls are used, the following additional checks on an AA's PKC chain MUST all succeed for the AC to be valid:
AAControlsを使用する場合、ACが有効であるためには、AAのPKCチェーンに対する次の追加チェックがすべて成功する必要があります。
1. Some CA on the AC's certificate path MUST be directly trusted to issue PKCs that precede the AC issuer in the certification path; call this CA the "AA CA".
1. ACの証明書パス上の一部のCAは、認証パスでAC発行者の前にあるPKCを発行することを直接信頼する必要があります。このCAを「AA CA」と呼びます。
2. All PKCs on the path from the AA CA, down to and including the AC issuer's PKC, MUST contain an AAControls extension; however, the PKC of the AA CA need not contain this extension.
2. AA CAからAC発行者のPKCまでのパス上のすべてのPKCには、AAControls拡張が含まれている必要があります。ただし、AA CAのPKCにこの拡張を含める必要はありません。
3. Only those attributes in the AC that are allowed, according to all of the AAControls extension values in all of the PKCs from the AA CA to the AC issuer, may be used for authorization decisions; all other attributes MUST be ignored. This check MUST be applied to the list of attributes following attribute decryption, and the id-aca-encAttrs type MUST also be checked.
3. AA CAからAC発行者へのすべてのPKCのすべてのAAControls拡張値に従って許可されているACの属性のみが、許可決定に使用できます。他のすべての属性は無視する必要があります。このチェックは、属性の復号化に続く属性のリストに適用する必要があり、id-aca-encAttrsタイプもチェックする必要があります。
name id-pe-aaControls OID { id-pe 6 } syntax AAControls criticality MAY be TRUE
name id-pe-aaControls OID {id-pe 6}構文AAControls重要度はTRUEになる場合があります
The protection afforded for private keys is a critical factor in maintaining security. Failure of AC issuers to protect their private keys will permit an attacker to masquerade as them, potentially generating false ACs or revocation status. Existence of bogus ACs and revocation status will undermine confidence in the system. If the compromise is detected, all ACs issued by the AC issuer MUST be revoked. Rebuilding after such a compromise will be problematic, so AC issuers are advised to implement a combination of strong technical measures (e.g., tamper-resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident.
秘密鍵に提供される保護は、セキュリティを維持する上で重要な要素です。 AC発行者が秘密キーを保護できない場合、攻撃者が偽装して、偽のACまたは失効ステータスを生成する可能性があります。偽のACの存在と失効ステータスは、システムへの信頼を損ないます。侵害が検出された場合、AC発行者が発行したすべてのACを取り消す必要があります。このような妥協後の再構築には問題があるため、AC発行者は、このようなインシデントを回避するために、強力な技術的手段（耐タンパー性のある暗号化モジュールなど）と適切な管理手順（職務の分離など）を組み合わせて実装することをお勧めします。
Loss of an AC issuer's private signing key may also be problematic. The AC issuer would not be able to produce revocation status or perform AC renewal. AC issuers are advised to maintain secure backup for signing keys. The security of the key backup procedures is a critical factor in avoiding key compromise.
AC発行者の秘密署名鍵の紛失も問題となる場合があります。 AC発行者は、失効ステータスを生成したり、AC更新を実行したりできません。 AC発行者は、署名鍵の安全なバックアップを維持することをお勧めします。キーのバックアップ手順のセキュリティは、キーの侵害を回避するための重要な要素です。
The availability and freshness of revocation status will affect the degree of assurance that should be placed in a long-lived AC. While long-lived ACs expire naturally, events may occur during its natural lifetime that negate the binding between the AC holder and the attributes. If revocation status is untimely or unavailable, the assurance associated with the binding is clearly reduced.
失効ステータスの可用性と鮮度は、長期間有効なACに配置する必要がある保証の程度に影響します。長期間有効なACは自然に期限切れになりますが、ACホルダーと属性の間のバインディングを無効にするイベントがその自然な有効期間中に発生する可能性があります。失効ステータスが早すぎるか利用できない場合、バインディングに関連する保証は明らかに低下します。
The binding between an AC holder and attributes cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of an AC. AC issuers are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
ACホルダーと属性の間のバインディングは、署名の生成に使用される暗号化モジュールの実装とアルゴリズムよりも強くなることはできません。短いキーの長さまたは弱いハッシュアルゴリズムは、ACのユーティリティを制限します。 AC発行者は強力な暗号技術を使用できるように、暗号の進歩に注意することをお勧めします。
Inconsistent application of name comparison rules may result in acceptance of invalid targeted or proxied ACs, or rejection of valid ones. The X.500 series of specifications defines rules for comparing distinguished names. These rules require comparison of strings without regard to case, character set, multi-character white space substrings, or leading and trailing white space. This specification and [PKIXPROF] relaxes these requirements, requiring support for binary comparison at a minimum.
名前比較規則の一貫性のない適用は、無効なターゲットACまたはプロキシACの受け入れ、または有効なACの拒否をもたらす可能性があります。 X.500シリーズの仕様は、識別名を比較するためのルールを定義しています。これらのルールでは、大文字、小文字、文字セット、複数文字の空白の部分文字列、または先頭と末尾の空白に関係なく、文字列を比較する必要があります。この仕様と[PKIXPROF]はこれらの要件を緩和し、少なくともバイナリ比較のサポートを必要とします。
AC issuers MUST encode the distinguished name in the AC holder.entityName field identically to the distinguished name in the holder's PKC. If different encodings are used, implementations of this specification may fail to recognize that the AC and PKC belong to the same entity.
AC発行者は、ACホルダーのPKCの識別名と同じように、ACホルダー.entityNameフィールドの識別名をエンコードする必要があります。異なるエンコーディングが使用されている場合、この仕様の実装は、ACとPKCが同じエンティティに属していることを認識できない場合があります。
If an attribute certificate is tied to the holder's PKC using the baseCertificateID component of the Holder field and the PKI in use includes a rogue CA with the same issuer name specified in the baseCertificateID component, this rogue CA could issue a PKC to a malicious party, using the same issuer name and serial number as the proper holder's PKC. Then the malicious party could use this PKC in conjunction with the AC. This scenario SHOULD be avoided by properly managing and configuring the PKI so that there cannot be two CAs with the same name. Another alternative is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. Failing this, AC verifiers have to establish (using other means) that the potential collisions cannot actually occur, for example, the Certificate Practice Statements (CPSs) of the CAs involved may make it clear that no such name collisions can occur.
ホルダーフィールドのbaseCertificateIDコンポーネントを使用して属性証明書がホルダーのPKCに関連付けられ、使用中のPKIにbaseCertificateIDコンポーネントで指定された同じ発行者名の不正なCAが含まれている場合、この不正なCAが悪意のあるパーティーにPKCを発行する可能性があります。適切な所有者のPKCと同じ発行者名とシリアル番号を使用します。その後、悪意のある当事者は、ACと組み合わせてこのPKCを使用できます。このシナリオは、PKIを適切に管理および構成して、同じ名前のCAが2つ存在しないようにすることで回避する必要があります。別の方法は、ObjectDigestInfoフィールドでpublicKeyCertタイプを使用してACをPKCに関連付けることです。これに失敗すると、AC検証者は（他の手段を使用して）潜在的な衝突が実際には発生しないことを確立する必要があります。たとえば、関係するCAの証明書実践ステートメント（CPS）は、そのような名前の衝突が発生しないことを明確にする場合があります。
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present MUST be ignored. Given that the AAControls PKC extension is optional to implement, AC verifiers MUST be provided with this information by other means. Configuration information is a likely alternative means. This becomes very important if an AC verifier trusts more than one AC issuer.
実装者は、ACの検証に続いて、発行者が発行することが信頼されている属性のみが承認の決定に使用されるようにする必要があります。存在してもよい他の属性は無視されなければなりません（MUST）。 AAControls PKC拡張機能の実装はオプションであることを考えると、AC検証者は他の方法でこの情報を提供しなければなりません（MUST）。構成情報はおそらく代替手段です。これは、AC検証者が複数のAC発行者を信頼する場合に非常に重要になります。
There is often a requirement to map between the authentication supplied by a particular security protocol (e.g., TLS, S/MIME) and the AC holder's identity. If the authentication uses PKCs, then this mapping is straightforward. However, it is envisaged that ACs will also be used in environments where the holder may be authenticated using other means. Implementers SHOULD be very careful in mapping the authenticated identity to the AC holder, especially when the authenticated identity does not come from a public key certificate as link between identity and AC may not be as "strong".
多くの場合、特定のセキュリティプロトコル（TLS、S / MIMEなど）によって提供される認証とAC所有者のIDをマッピングする必要があります。認証でPKCを使用する場合、このマッピングは簡単です。ただし、所有者が他の手段を使用して認証される可能性がある環境でもACが使用されることが想定されます。特にIDとACの間のリンクが「強力」ではない可能性があるため、認証済みIDが公開鍵証明書に由来しない場合は、実装者は認証済みIDをACホルダーにマッピングする際に非常に注意する必要があります。
Attributes and attribute certificate extensions are identified by object identifiers (OIDs). Many of the OIDs used in this document are copied from X.509 [X.509-2000]. Other OIDs were assigned from an arc delegated by the IANA to the PKIX working group. No further action by the IANA is necessary for this document or any anticipated updates.
属性と属性証明書拡張機能は、オブジェクト識別子（OID）によって識別されます。このドキュメントで使用されているOIDの多くは、X.509 [X.509-2000]からコピーされています。他のOIDは、IANAによって委任された弧からPKIXワーキンググループに割り当てられました。このドキュメントまたは予想される更新については、IANAによるさらなるアクションは必要ありません。
[PKIXALGS] refers to [RFC3279], [RFC4055], [RFC5480], and [RFC5756].
[PKIXALGS]は[RFC3279]、[RFC4055]、[RFC5480]、および[RFC5756]を指します。
[Err302] RFC Errata, Errata ID 302, RFC 3281, http://www.rfc-editor.org.
[Err302] RFC Errata、Errata ID 302、RFC 3281、http：//www.rfc-editor.org。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 5652、2009年9月。
[HTTP-URL] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[HTTP-URL] Housley、R。およびP. Hoffman、「Internet X.509 Public Key Infrastructure Operational Protocols：FTP and HTTP」、RFC 2585、1999年5月。
[LDAP-URL] Smith, M., Ed., and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[LDAP-URL] Smith、M.、Ed。、およびT. Howes、「Lightweight Directory Access Protocol（LDAP）：Uniform Resource Locator」、RFC 4516、2006年6月。
[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月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W.、and R. Housley、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3279、April 2002。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、2005年6月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[RFC5756] Turner, S. Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, January 2010.
[RFC5756]ターナー、S。ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「RSAES-OAEPおよびRSASSA-PSSアルゴリズムパラメーターの更新」、RFC 5756、2010年1月。
[PKIXPROF] 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.
[PKIXPROF] 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月。
[X509-SRV] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[X509-SRV] Santesson、S。、「Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name」、RFC 4985、2007年8月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.680] ITU-T勧告X.680（2002）| ISO / IEC 8824-1：2002、情報技術-抽象構文記法1（ASN.1）：基本記法の仕様。
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690] ITU-T勧告X.690（2002）| ISO / IEC 8825-1：2002、情報技術-ASN.1エンコーディングルール：Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）およびDistinguished Encoding Rules（DER）の仕様。
[KRB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KRB] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[LDAP] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[LDAP] Sermersheim、J.、Ed。、 "Lightweight Directory Access Protocol（LDAP）：The Protocol"、RFC 4511、June 2006。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年6月。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[RFC3281] Farrell、S。およびR. Housley、「承認のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
[X.500-2000] ITU-T Recommendation X.500 (2000) | ISO/IEC 9594-1:2000, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.
[X.500-2000] ITU-T勧告X.500（2000）| ISO / IEC 9594-1：2000、情報技術-オープンシステム相互接続-ディレクトリ：概念、モデル、およびサービスの概要。
[X.501-1993] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1993, Information technology - Open Systems Interconnection - The Directory: Models.
[X.501-1993] ITU-T勧告X.501（1993）| ISO / IEC 9594-2：1993、情報技術-オープンシステム相互接続-ディレクトリ：モデル。
[X.501-1997] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997, Information technology - Open Systems Interconnection - The Directory: Models.
[X.501-1997] ITU-T勧告X.501（1997）| ISO / IEC 9594-2：1997、情報技術-オープンシステム相互接続-ディレクトリ：モデル。
[X.509-1988] CCITT Recommendation X.509: The Directory - Authentication Framework, 1988.
[X.509-1988] CCITT勧告X.509：ディレクトリ-認証フレームワーク、1988。
[X.509-1997] ITU-T Recommendation X.509: The Directory - Authentication Framework, 1997.
[X.509-1997] ITU-T勧告X.509：ディレクトリ-認証フレームワーク、1997年。
[X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key and Attribute Certificate Frameworks, 2000.
[X.509-2000] ITU-T勧告X.509：The Directory-Public-Key and Attribute Certificate Frameworks、2000。
This (normative) appendix lists the new object identifiers that are defined in this specification. Some of these are required only for support of optional features and are not required for conformance to this profile. This specification mandates support for OIDs that have arc elements with values that are less than 2^32, (i.e., they MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less than 2^31 (i.e., less than or equal to 2,147,483,647). This allows each arc element to be represented within a single 32-bit word. Implementations MUST also support OIDs where the length of the dotted decimal (see [LDAP], Section 4.1.2) string representation can be up to 100 bytes (inclusive). Implementations MUST be able to handle OIDs with up to 20 elements (inclusive). AAs SHOULD NOT issue ACs that contain OIDs that breach these requirements.
この（規範的な）付録は、この仕様で定義されている新しいオブジェクト識別子の一覧です。これらの一部はオプション機能のサポートにのみ必要であり、このプロファイルへの準拠には必要ありません。この仕様は、2 ^ 32未満（つまり、0から4,294,967,295までの値でなければならない）のアーク要素を持つOIDのサポートを必須とし、2 ^ 31未満（つまり、2,147,483,647以下）である必要があります。 。これにより、各弧要素を単一の32ビットワード内で表すことができます。実装では、ドット付き10進数（[LDAP]、セクション4.1.2を参照）の長さが最大100バイト（両端を含む）であるOIDもサポートする必要があります。実装は、最大20要素（両端を含む）のOIDを処理できる必要があります。 AAは、これらの要件に違反するOIDを含むACを発行しないでください。
The following OIDs are imported from [PKIXPROF]:
次のOIDは[PKIXPROF]からインポートされます。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
The following new ASN.1 module OID is defined:
次の新しいASN.1モジュールOIDが定義されています。
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
The following AC extension OIDs are defined:
次のAC拡張OIDが定義されています。
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
The following PKC extension OIDs are defined:
以下のPKC拡張OIDが定義されています。
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
The following attribute OIDs are defined:
次の属性OIDが定義されています。
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
clearance (55) }
As noted in Section 4.4.6, there are two OIDs for id-at-clearance.
セクション4.4.6で述べたように、id-at-clearanceには2つのOIDがあります。
This appendix describes data objects used by conforming PKI components in an "ASN.1-like" syntax [X.680]. This syntax is a hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 UNIVERSAL Types UniversalString, BMPString, and UTF8String.
この付録では、「ASN.1のような」構文[X.680]でPKIコンポーネントを適合させることによって使用されるデータオブジェクトについて説明します。この構文は、1988年と1993年のASN.1構文のハイブリッドです。 1988 ASN.1構文は、1993年のUNIVERSALタイプのUniversalString、BMPString、およびUTF8Stringで拡張されています。
The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard.
ASN.1構文では、ASN.1モジュールに型ステートメントを含めることはできません。また、1993 ASN.1標準では、1988構文を使用するモジュールで新しいUNIVERSAL型を使用できません。その結果、このモジュールはASN.1標準のどちらのバージョンにも準拠していません。
This appendix may be converted into 1988 ASN.1 by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
この付録は、UNIVERSALタイプの定義を1988キャッチオール「ANY」で置き換えることにより、1988 ASN.1に変換できます。
PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-v2(61) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
-すべてエクスポート-
IMPORTS
輸入
-- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-- PKIX Certificate Extensions
Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(18) }
GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
AuthorityInfoAccessSyntax, CRLDistributionPoint
FROM PKIX1Implicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(19) }
ContentInfo
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
;
；
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
-- { id-aca 5 } is reserved
-{id-aca 5}は予約されています
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
-- Uncomment the following declaration and comment the above line if
-- using the id-at-clearance attribute as defined in [RFC3281]
-- id-at-clearance OBJECT IDENTIFIER ::= {
-- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) }
-- Uncomment this if using a 1988 level ASN.1 compiler
-1988レベルのASN.1コンパイラを使用している場合は、これをコメント解除します
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the
-- holder, for example, an executable
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST
-- NOT be present in this profile
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
-- Uncomment the following lines to support deprecated clearance
-- syntax and comment out previous Clearance.
-- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory OPTIONAL
-- }
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
-- Note that in [RFC3281] the syntax for SecurityCategory was
-- as follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encoding.
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ProxyInfo ::= SEQUENCE OF Targets
END
終わり
The following is the errata report submitted against RFC 3281, posted online as [Err302].
以下は、RFC 3281に対して提出された、[Err302]としてオンラインで投稿されたエラッタレポートです。
Status: Verified
ステータス：確認済み
Type: Technical
タイプ：テクニカル
Reported By: Stephen Farrell
報告者：スティーブンファレル
Date Reported: 2003-03-07
報告日：2003-03-07
Section 4.4.6 says:
セクション4.4.6は言う：
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
It should say:
それは言うべきです：
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Notes:
ノート：
The differences in tagging arose due to an unnoticed technical corrigendum (TC-2) being applied to the X.501 document during preparation of RFC 3281. The X.501 format is the correct form and will be included in a future update of RFC 3281. Implementers SHOULD modify their decoding functions to accept either format and, even if claiming RFC 3281 conformance, SHOULD output the (correct) X.501 format pending the issuing of a corrected RFC at which point the incorrect RFC 3281 format will no longer be specified.
タグ付けの違いは、RFC 3281の準備中にX.501ドキュメントに適用された気付かれていない技術的正誤表（TC-2）が原因で発生しました。X.501形式は正しい形式であり、RFC 3281の将来の更新に含まれる予定です。実装者は、いずれかの形式を受け入れるようにデコード関数を変更する必要があります。また、RFC 3281準拠を主張している場合でも、修正されたRFCの発行が保留される（正しい）X.501形式を出力する必要があります（SHOULD）。この時点で、不正なRFC 3281形式は指定されなくなります。
1. Created a new Section 1.1 "Terminology", renumbered Sections 1.1-1.3 to 1.2-1.4, and moved first paragraph of Section 1 to Section 1.1.
1. 新しいセクション1.1「用語」を作成し、セクション1.1-1.3から1.2-1.4に番号を付け直し、セクション1の最初の段落をセクション1.1に移動しました。
2. In Section 1.2, rephrased first sentence in third paragraph.
2. セクション1.2では、第3段落の最初の文を言い換えました。
3. In Section 2, replaced S/MIME v3 with S/MIME v3.2.
3. セクション2で、S / MIME v3をS / MIME v3.2に置き換えました。
4. In Section 4.1, moved "," from the right of the ASN.1 comment to the left of the ASN.1 comment on the line describing version in the AttributeCertificateInfo structure. Replaced reference to X.208 with X.690.
4. セクション4.1で、「、」をASN.1コメントの右側からASN.1コメントの左側に、AttributeCertificateInfo構造体のバージョンを説明する行に移動しました。 X.208への参照をX.690に置き換えました。
5. In Section 4.2, replaced pointer to 4.2.1.7 of RFC 3280 with pointer to 4.2.1.6 of RFC 5280. Added requirement to support subject alternative name choice SRVName.
5. セクション4.2で、RFC 3280の4.2.1.7へのポインターをRFC 5280の4.2.1.6へのポインターに置き換えました。サブジェクトの別名の選択SRVNameをサポートするための要件を追加しました。
6. In Section 4.3.2, replaced "Confirming" with "Conforming".
6. 4.3.2項で、「確認」を「適合」に置き換えました。
7. In Section 4.3.4, replaced reference to RFC 1738, URL, with references to [HTTP-URL], "authorityInformationAccess" with "authorityInfoAccess", and "NOT REQUIRED" with "OPTIONAL."
7. セクション4.3.4で、RFC 1738、URLへの参照を[HTTP-URL]への参照、「authorityInformationAccess」を「authorityInfoAccess」、「NOT REQUIRED」を「OPTIONAL」に置き換えました。
8. In Section 4.3.5, replaced "HTTP or an LDAP" with "HTTP [HTTP-URL] or an LDAP [LDAP-URL]". Also, replaced "CRLDistPointsSyntax" with "CRLDistributionPoints".
8. セクション4.3.5で、「HTTPまたはLDAP」を「HTTP [HTTP-URL]またはLDAP [LDAP-URL]」に置き換えました。また、「CRLDistPointsSyntax」を「CRLDistributionPoints」に置き換えました。
9. In Section 4.4.6, added text to address having two OIDs for the same syntax and two syntaxes for one OID.
9. セクション4.4.6で、同じ構文の2つのOIDと1つのOIDの2つの構文を持つアドレスにテキストを追加しました。
10. In Section 5, replaced "When the extension value SHOULD cause" with "When the extension value causes".
10. セクション5で、「拡張値が発生する必要がある場合」を「拡張値が発生する場合」に置き換えました。
11. In Section 7.1, replaced text that described encapsulating encrypted attribute with corrected text. Clarified that attributes can appear more than once if they apply to different recipients. Reworded last paragraph to more clearly describe the failure case.
11. セクション7.1で、暗号化された属性のカプセル化を説明するテキストを修正されたテキストに置き換えました。属性が異なる受信者に適用される場合、属性が複数回表示される可能性があることを明確にしました。失敗のケースをより明確に説明するために最後の段落を書き換えました。
12. In Section 7.3, updated references to point to RFC 3279.
12. セクション7.3で、RFC 3279を指すように参照を更新しました。
13. In Section 8, updated last paragraph to better explain why implementers need to be careful when mapping authenticated identities to the AC holder.
13. セクション8では、認証済みIDをAC所有者にマッピングするときに実装者が注意する必要がある理由をより詳しく説明するために最後の段落を更新しました。
14. Updated References: a) split references into informative/normative references b) added reference to RFC 3281 c) replaced reference to X.501:1993 with X.501:1997 d) replaced reference to RFC 1510 with RFC 4120 e) replaced reference to RFC 1738 with RFC 4516 and 2585 f) replaced reference to RFC 2251 with RFC 4511 g) replaced reference to RFC 2459 with RFC 5280 h) replaced reference to RFC 2630 with RFC 5652 i) replaced reference to X.208-1988 with X.690 j) added reference to X.680 k) added reference to RFC 4985 l) expanded reference to RFC 3279 by adding RFC 5480 and RFC 4055, which update RFC 3279 m) deleted spurious reference to CMC, CMP, ESS, RFC 2026, X.209-88, and X.501:1988.
14. 更新された参照：a）参照を情報/規範参照に分割b）RFC 3281への参照を追加c）X.501：1993への参照をX.501：1997に置き換えd）RFC 1510への参照をRFC 4120に置き換えe）参照を置き換えRFC 1738とRFC 4516および2585 f）RFC 2251への参照をRFC 4511に置換g）RFC 2459への参照をRFC 5280に置換h）RFC 2630への参照をRFC 5652に置換i）X.208-1988への参照をXに置換690 j）X.680への参照の追加k）RFC 4985への参照の追加l）RFC 3279を更新するRFC 5480とRFC 4055の追加によるRFC 3279への参照の拡張m）CMC、CMP、ESS、RFC 2026への偽の参照の削除X.209-88、およびX.501：1988。
15. In Appendix A, added second clearance attribute object identifier.
15. 付録Aに、2番目の認可上限属性オブジェクト識別子が追加されました。
16. Appendix B, updated ASN.1 with changes 3, 8, 9, and 11: a) New OID for ASN.1 module. b) Updated module OIDs for PKIX1Explicit88 and PKIX1Implicit88. c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier, AuthorityInfoAccessSyntax, CRLDistributionPoint. d) Added imports from CryptographicMessageSyntax2004 for ContentInfo. e) Added comments and commented out ASN.1 for old clearance attribute syntax. f) Added preamble to ASN.1, which is taken from Appendix A of RFC 5280.
16. 付録B、更新されたASN.1、変更3、8、9、および11：a）ASN.1モジュールの新しいOID。 b）PKIX1Explicit88およびPKIX1Implicit88のモジュールOIDを更新。 c）AuthorityKeyIdentifier、AuthorityInfoAccessSyntax、CRLDistributionPointのPKIX1Implicit88からのインポートを追加しました。 d）ContentInfoのCryptographicMessageSyntax2004からのインポートを追加しました。 e）コメントを追加し、古いクリアランス属性構文のASN.1をコメントアウトしました。 f）RFC 5280の付録Aから取られたASN.1にプリアンブルを追加しました。
17. Added Appendix C.
17. 付録Cを追加しました。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA EMail: turners@ieca.com
Sean Turner IECA、Inc. 3057 Nutley Street、Suite 106 Fairfax、VA 22031 USAメール：turners@ieca.com
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA Eメール：housley@vigilsec.com
Stephen Farrell Distributed Systems Group Computer Science Department Trinity College Dublin Ireland EMail: stephen.farrell@cs.tcd.ie
Stephen Farrell Distributed Systems Group Computer Science Department Trinity College Dublin Ireland Eメール：stephen.farrell@cs.tcd.ie