Network Working Group S. Farrell
Request for Comments: 3281 Baltimore Technologies
Category: Standards Track R. Housley
RSA Laboratories
April 2002
An Internet Attribute Certificate
Profile for Authorization
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この仕様は、インターネットプロトコルにおけるX.509属性証明書を使用するためのプロファイルを定義します。属性証明書は、相互運用性目標の広いスペクトルおよび運用と保証要件の広範囲をカバーするアプリケーションや環境の広い範囲で使用することができます。このドキュメントの目標は、幅広い相互運用性を必要とする一般的なアプリケーションだけでなく、限られた特別な目的の要件のための共通のベースラインを確立することです。インターネット、電子メール、IPSecの、およびWWWのセキュリティアプリケーションのための属性証明書のサポート上のプロファイルの場所を強調。
Table of Contents
目次
1. Introduction................................................. 2
1.1 Delegation and AC chains............................... 4
1.2 Attribute Certificate Distribution ("push" vs. "pull"). 4
1.3 Document Structure..................................... 6
2. Terminology.................................................. 6
3. Requirements................................................. 7
4. Attribute Certificate Profile................................ 7
4.1 X.509 Attribute Certificate Definition................. 8
4.2 Profile of Standard Fields............................. 10
4.2.1 Version.......................................... 10
4.2.2 Holder........................................... 11
4.2.3 Issuer........................................... 12
4.2.4 Signature........................................ 12
4.2.5 Serial Number.................................... 12
4.2.6 Validity Period.................................. 13
4.2.7 Attributes....................................... 13
4.2.8 Issuer Unique Identifier......................... 14
4.2.9 Extensions....................................... 14
4.3 Extensions............................................. 14
4.3.1 Audit Identity................................... 14
4.3.2 AC Targeting..................................... 15
4.3.3 Authority Key Identifier......................... 17
4.3.4 Authority Information Access..................... 17
4.3.5 CRL Distribution Points.......................... 17
4.3.6 No Revocation Available.......................... 18
4.4 Attribute Types........................................ 18
4.4.1 Service Authentication Information............... 19
4.4.2 Access Identity.................................. 19
4.4.3 Charging Identity................................ 20
4.4.4 Group............................................ 20
4.4.5 Role............................................. 20
4.4.6 Clearance........................................ 21
4.5 Profile of AC issuer's PKC............................. 22
5. Attribute Certificate Validation............................. 23
6. Revocation................................................... 24
7. Optional Features............................................ 25
7.1 Attribute Encryption................................... 25
7.2 Proxying............................................... 27
7.3 Use of ObjectDigestInfo................................ 28
7.4 AA Controls............................................ 29
8. Security Considerations...................................... 30
9. IANA Considerations.......................................... 32
10. References.................................................. 32
Appendix A: Object Identifiers.................................. 34
Appendix B: ASN.1 Module........................................ 35
Author's Addresses.............................................. 39
Acknowledgements................................................ 39
Full Copyright Statement........................................ 40
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 BCP 14, RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈されます。
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. The syntax for the AC is defined in Recommendation X.509, making the term "X.509 certificate" ambiguous.
X.509公開鍵証明書（PKCS）[X.509-1997、X.509-2000、PKIXPROF]はアイデンティティと公開鍵をバインドします。属性証明書（AC）は、PKCと同様の構造です。主な違いは、ACは一切公開鍵が含まれていないことであること。 ACは、グループのメンバーシップ、役割、セキュリティクリアランス、またはACホルダーに関連する他の認証情報を指定する属性が含まれていてもよいです。 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とACSを混乱させる。アナロジーは、区別を明確にすることがあります。 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での認証情報の配置は、二つの理由から、通常は望ましくありません。まず、認証情報は、多くの場合、アイデンティティと公開鍵の結合と同じ寿命を持っていません。認可情報がPKC拡張に配置される場合、一般的な結果は、PKCの有用な寿命の短縮です。第二に、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から承認情報を分離することが多い方がよいです。しかし、認証情報もアイデンティティにバインドする必要があります。 ACは、この結合を提供します。それは単にデジタル署名された（または認定）のアイデンティティと属性のセットです。
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ホルダーがアクセスを要求しているエンティティであることを確認する必要があるかもしれません。要求又はアイデンティティと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.
ACSは、データ発信元認証サービス及び否認防止サービスの文脈で使用されてもよいです。これらの状況では、ACに含まれる属性は、署名エンティティに関する追加情報を提供します。この情報は、エンティティがデータに署名する権限があることを確認するために使用することができます。チェックのこの種のデータが交換されるコンテキストにまたはデジタル署名されたデータのどちらかに依存します。
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]「そのような権限を保持している一方のエンティティから別のエンティティに権限の搬送」として認可を定義します。 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, this specification does NOT RECOMMEND the use of 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].
これは、適合実装は、一度に単一のACを処理できることが要求されることを意味します。複数のAC、次々、の処理が必要になることがあります。但し【PKIXPROF]で指定されるように、ACの検証は、の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.
上述したように、ACSは、例えば、アクセス制御決定機能を確実に認証情報を提供するためのメカニズムを提供します。しかし、ACSの可能な通信パスの数があります。
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.
クライアント、サーバー、およびAC発行者：3つのエンティティが関与する可能交換の数があります。また、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は、ACSを含むことができる交流の抽象的ビューを示します。このプロファイルは、これらの交換のためのプロトコルを指定しません。
+--------------+
| | Server Acquisition
| AC issuer +----------------------------+
| | |
+--+-----------+ |
| |
| Client |
| Acquisition |
| |
+--+-----------+ +--+------------+
| | 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 which MAY be supported; however, support for these features is not required for conformance to this profile. Finally, appendices contain the list of 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 S/MIME v3 context, where the mail user agent would be both a "client" and a "server" in the sense the terms are used here.
簡単にするために、我々は、この仕様書で用語クライアントとサーバを使用しています。これは、ACSが唯一のクライアントサーバ環境で使用されるようにしていることを示すことを意図していません。たとえば、ACSは、メールユーザエージェントは、「クライアント」との用語は、ここで使用されている意味での「サーバー」の両方になり、S / MIME v3のコンテキストで使用することができます。
Term Meaning
用語の意味
AA Attribute Authority, the entity that issues the AC, synonymous in this specification with "AC issuer" AC Attribute Certificate AC user any entity that parses or processes an AC AC verifier any entity that checks the validity of an AC and then makes use of the result AC issuer the entity which signs the AC, synonymous in this specification with "AA" AC holder the entity indicated (perhaps indirectly) in the holder field of the AC Client the entity which 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 type ASN.1 Certificate defined in X.509 and profiled in RFC 2459. This (non-standard) acronym is used in order to avoid confusion about the term "X.509 certificate". Server the entity which requires that the authorization checks are made
AAは、「AC発行者」と本明細書では同義当局、ACを発行するエンティティを、属性ACは、解析したりAC AC検証にACの妥当性をチェックする任意のエンティティを処理して任意のエンティティの証明書ACのユーザー属性、その後を使用しています「AA」ACホルダと本明細書では同義ACに署名するエンティティ、エンティティがACクライアントのホルダーフィールドに（おそらく間接的に）認証チェックがなされるべきであるため、アクションを要求しているエンティティを示すAC発行者をもたらします本明細書ではプロキシは、プロキシは、アプリケーションサーバは、ユーザに代わって、アプリケーション・クライアントとして動作する状況を意味するために使用されます。ここでのプロキシは、権限の付与を意味するものではありません。 PKC公開鍵証明書は - タイプのASN.1証明書この（非標準）頭字語は用語「X.509証明書」についての混乱を避けるために使用されているX.509で定義され、RFC 2459でプロファイルを使用しています。サーバーの認証チェックが行われていることを必要とするエンティティ
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.
住んでいた、短いだけでなく、長寿命のAC 1.サポート。 PKCのために数ヶ月とは対照的に、典型的な短命の有効期間は、時間単位で測定される可能性があります。短い有効期間は、ACSが取り消し機構なしに有用であることができます。
Attribute Types:
タイプ属性：
2. Issuers of ACs should be able to define their own attribute types for use within closed domains.
AC 2.発行者は、クローズドドメイン内で使用するために、独自の属性タイプを定義することができるはずです。
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の内に含まれることができるいくつかの標準属性タイプは、定義されなければなりません。例としては、「アクセスアイデンティティ」「グループ」「役割」、「クリアランス」、「監査のアイデンティティ、」とが含ま「アイデンティティを充電します。」
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検証を可能にするように定義されるべきです。例えば、ボルチモアとSPYRUSで定義されている「管理者グループ」によって定義される「管理者グループは、」容易に区別する必要があります。
Targeting of ACs:
ACSターゲット：
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. 1つ、またはサーバ、少数の時にACを「ターゲット」ことが可能であるべきです。これは、信頼できる非対象サーバは、認可の決定のための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. ACSは定義されるべきです。
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.
ACSは、相互運用性の目標や運用及び保証要件の広いスペクトルの広いスペクトルをカバーするアプリケーションや環境の広い範囲で使用することができます。このドキュメントの目標は、幅広い相互運用性と限られた特別な目的の要件を必要とする一般的なアプリケーションのための共通のベースラインを確立することです。特に、重点は非公式のインターネット、電子メール、IPSecの、およびWWWアプリケーションの属性証明書の使用をサポートすることになります。
This section presents a profile for ACs that will foster interoperability. This section also defines some private extensions for the Internet community.
このセクションでは、相互運用性を促進しますACSのプロファイルを提示します。また、このセクションでは、インターネットコミュニティのためのいくつかのプライベート拡張を定義します。
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文書は、ASN.1の1993（またはそれ以降）のバージョンを使用しながらの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 }
エンティティネーム[1] GeneralNames OPTIONAL、 - 請求者またはロールの名前objectDigestInfo [2] ObjectDigestInfo OPTIONAL - 直接ホルダーを認証するために使用、 - 例えば、実行}
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.208-1988]) 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.
実装は、値のセットのDER符号化は（[X.208-1988]、[X.509- 1988]を参照）の値の符号化の順序を必要とすることに注意すべきです。この問題が識別名に対して生じ、そして[PKIXPROF】実装によって処理されなければならないものの、複数の値を含めることは、ACSにはるかに一般的であるので、それは、はるかに重要この文脈です。
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.7).
準拠した実装はのdNSName、directoryNameで、uniformResourceIdentifierで、及びIPアドレスオプションをサポートできなければなりません。これは、（主セクション4.2.1.7で）PKIXPROF]でのGeneralName要件と互換性があります。
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options.
準拠した実装はx400Address、ediPartyName、またはregisteredIDオプションを使用してはなりません。
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オプションを使用するかもしれません。例えば、ケルベロス[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. 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.
baseCertificateID、エンティティネームとobjectDigestInfo：ホルダーフィールドは、3つの異なる（オプション）構文を可能にする配列です。唯一のオプションが存在する場合、ホルダフィールドの意味は明確です。複数のオプションが使用される場合、正しい位置が[X.509-2000]、このことから明らかではないので、「ヒント」等であり、「規範的」はオプションであるようしかし、混乱する可能性があります仕様はオプションのうち1つだけが任意の所与のACで使用することをお勧めします。
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の使用に基づいて認証されたメッセージまたはセッションとに渡される任意の環境のために、ホルダフィールドがbaseCertificateIDを使用すべきです。
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 which 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]) which mandate that the PKC issuer field contain a non-empty distinguished name value.
baseCertificateIDオプションを使用すると、保有者のPKCのserialNumberと発行者は、ACホルダーフィールドと同じでなければなりません。 PKC発行者はholder.baseCertificateID.issuerの単一の値がdirectoryNameでフィールドに構築物として存在することがある、空でない識別名がなければなりません。保有者のPKCはissuerUniqueIDフィールドが含まれている場合、AC holder.baseCertificateID.issuerUIDフィールドにのみ使用しなければなりません。 AC holder.baseCertificateID.issuerUIDおよびPKC issuerUniqueIDフィールドの両方が存在する場合、同じ値が両方のフィールドに存在していなければなりません。したがって、baseCertificateIDが空でない識別名値を含むPKC発行者フィールドた委任（[PKIXPROF]など）PKCプロファイルでのみ使用可能です。
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.
ホルダーフィールドは、エンティティネームオプションを使用して、基礎となる認証がPKCに基づいている場合、エンティティネームはPKC件名フィールドまたはPKCのsubjectAltNameフィールド拡張（存在する場合）の値と同じでなければなりません。 PKC対象が空の識別名である場合subjectAltName拡張が存在する[PKIXPROF]任務ことに留意されたいです。エンティティネームオプションを使用するときに発生する可能性があるいくつかの名前の衝突の問題に言及し、セキュリティ上の考慮事項のセクションを参照してください。
In any other case where the holder field uses the entityName option, only one name SHOULD be present.
ホルダーフィールドは、エンティティネームオプションを使用する任意の他の場合には、唯一の名前が存在しなければなりません。
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ホルダーオプション指定とすべきで、これはそのプロトコルで定義されているサポートされている認証スキームにどのように適合しますか。
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.
このプロファイルに準拠したACSはdirectoryNameでフィールドに空でない識別名を含まなければならない1とissuerNameで唯一のGeneralNameを含まなければならないv2Formの選択を、使用しなければなりません。これは、すべてのACの発行体が空でない識別名を持っていなければならないことを意味します。このプロファイルに準拠したACSはbaseCertificateIDとobjectDigestInfoフィールドを省略しなければなりません。
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検証が（AC発行者）のために使用されますPKCかを知る必要がないことを意味するということです。 ACの発行者を参照するためにbaseCertificateIDフィールドを使用すると、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]. Conforming implementations MUST honor all MUST/SHOULD/MAY signing algorithm statements specified in [PKIXALGS].
これは、[PKIXALGS]で定義された署名アルゴリズムのいずれかでなければなりません。準拠した実装はすべて、/ / [PKIXALGS]で指定されたアルゴリズム文に署名するかもしれべきであるしなければならない尊重しなければなりません。
For any conforming AC, the issuer/serialNumber pair MUST form a unique combination, even if ACs are very short-lived.
任意の適合するACの場合は、発行人/ serialNumberをペアは、ACSが非常に短命であっても、ユニークな組み合わせを形成しなければなりません。
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発行者は、すなわち、INTEGER値のDER符号化における符号ビットがゼロでなければならない正の整数であることのserialNumberを強制しなければならない - これは、必要に応じて先頭の（最左）「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の値を扱うことができなければなりません。準拠ACSは、20オクテットより長いserialNumberの値を含めることはできません。
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.)
（注：これは、セクション4.1.2.5.2 [PKIXPROF]で指定されたものと同じです。）
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 MAY contain 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.
属性フィールドは、属性の配列を含みます。各属性は、値のセットを含むかもしれません。与えられたACの場合は、シーケンス内の各AttributeTypeでオブジェクト識別子は一意でなければなりません。つまり、各属性の唯一のインスタンスは、単一のACで起こり得るが、各インスタンスは、多値であってもよいです。
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つの属性を含まなければなりません。つまり、属性の配列はゼロ長さではいけません。
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 CAs, but that applications SHOULD be able to parse PKCs containing the field.
また、それを使用しなければなりません。その場合には、ACの発行者のPKCに使用されていない限り、このフィールドを使用してはいけません。 [PKIXPROF]このフィールドは、CAを準拠することにより、使用すべきではないことが、アプリケーションは、フィールドを含むの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 which might prevent use in a general context.
ACSの定義された拡張子が保有して追加の属性を関連付けるための方法を提供します。このプロファイルはまた、コミュニティは、これらのコミュニティに固有の情報を運ぶためにプライベート拡張を定義することができます。 ACの各拡張は、クリティカルまたは非クリティカルとして指定することができます。それはそれは認識していない重要な拡張が発生した場合AC使用したシステムは、ACを拒絶しなければなりません。それが認識されない場合が、非クリティカルな拡張は無視することができます。 4.3節のプレゼントは、インターネットACSとの情報のための標準的な場所内で使用される拡張をお勧めします。コミュニティには、追加の拡張機能を使用するために選択することができ、ただし、注意が一般的な文脈での使用を妨げる可能性があるACSのいずれかの重要な拡張を採用する行使されなければなりません。
In some circumstances, it is required (e.g. by data protection/data privacy legislation) that audit trails not contain records which 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が監査アイデンティティの拡張子を含むかもしれません。理想的には、AC発行者の協力なしには、監査ID値からAC保有者の身元を導出する実行不可能であるべきです。
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.
AC発行者/シリアルと共に監査同一性の値は、その後、監査/ロギングのために使用されてください。監査同一の値が適切に選択された場合、サーバ/サービスの管理者は、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発行者が監査アイデンティティからACホルダの実際の同一性を決定することができなければならないことを意味します。
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発行者/シリアル対に基づくことができます。しかし、この方法は、複数のACSと同じ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.
ACSを使用するプロトコルは、多くの場合、オン・ザ・ワイヤビットにACホルダの身元を公開します。このような場合には、不透明な監査アイデンティティは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.
監査アイデンティティの値がゼロオクテットより長くなければなりません。監査アイデンティティの値が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}構文オクテットストリング臨界が真でなければなりません
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.
【X.509-2000]からインポートAC、ターゲット情報拡張を、標的とするために、サーバ/サービスの数を指定するために使用されるかもしれません。その意図は、ACのみ指定されたサーバー/サービスで使用可能でなければならないことです。名前のサーバ/サービスの中ではありません（正直）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.
標的構造内targetCert選択は[X.509-2000]との将来の互換性を可能にするためにのみ存在し、使用してはいけません。
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.
ターゲットは、現在のサーバー（受信者）は、ターゲット配列中のターゲット名フィールドのいずれかである場合、または現在のサーバがターゲット配列中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は「プリンタ」を指定し、AC検証は、プリンタやプリントサーバであるかどうかを知っています。
Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF Targets". Conforming AC issuer implementations MUST only produce one "Targets" element. Confirming 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発行者の実装は唯一の「ターゲット」要素を生成しなければなりません。確認ACユーザーは「目標のSEQUENCE」を受け入れることができなければなりません。複数のターゲット要素はACで見つかった場合、拡張子はすべてのターゲット要素が1つのターゲット要素内で発見されたかのように扱われなければなりません。
name id-ce-targetInformation OID { id-ce 55 } syntax SEQUENCE OF Targets criticality MUST be TRUE
名前ID-CE-targetInformation OID {ID-CE 55}ターゲット臨界構文配列が真でなければなりません
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.
authorityKeyIdentifier拡張は、[PKIXPROF]にプロファイルとして、ACの署名をチェックすることAC検証を支援するために使用されるかもしれません。 【PKIXPROF]説明を意味する「CA」かのように読まれるべきである「AC発行者」。 PKCと同じように、この拡張機能は、ACSに含まれるべきです。
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で）、ACSが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 authorityInformationAccess 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 NOT REQUIRED by this profile since AC chains are not expected.
authorityInformationAccess拡張は、[PKIXPROF]で定義されるように、ACの失効状態を確認するにAC検証を支援するために使用されるかもしれません。 AC鎖が期待されていないので、ID-広告caIssuersたaccessMethodのサポートは、このプロファイルでは不要です。
The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the OCSP protocol 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 [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 [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.
crlDistributionPoints拡張は、[PKIXPROF]にプロファイルとして、ACの失効状態を確認するにAC検証を支援するために使用されるかもしれません。失効の詳細については、セクション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 or an LDAP URL [URL].
crlDistributionPoints拡張子が存在する場合、正確に1つの配布ポイントが存在しなければなりません。 crlDistributionPoints拡張は、単一の名前の形式を含まなければならないのfullNameを含まなければならないDistributionPointNameオプションを使用する必要があります。この名前は、識別名またはURIのいずれかを含まなければなりません。 URIは、HTTP URLまたはLDAP URL [URL]のいずれかでなければなりません。
name id-ce-cRLDistributionPoints OID { id-ce 31 } syntax CRLDistPointsSyntax criticality MUST be FALSE
名前ID-CE-cRLDistributionPoints OID {ID-CE 31}構文CRLDistPointsSyntax臨界が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
名前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を、オブジェクト識別子、およびUTF8Stringを、に制限されています。各値は、値の構文の同じ選択を使用しなければならないように、この構文を使用して、すべての複数値の属性が制限されています。例えば、AC発行者は、OIDと文字列と第二の値との値を使用してはなりません。
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内の複数の値」タグ。これはAttributeValuesのセットを指します。セクション4.2.7で指定されAttributeTypeではまだ一度だけ発生します。
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ホルダーを識別し、属性はオプションサービス固有の認証情報を含むことができます。通常、これは「レガシー」アプリケーション用のユーザー名/パスワードのペアが含まれています。
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.
AUTHINFOフィールドはパスワードなど、機密性の高い情報が含まれている場合、この属性の型は、一般的に暗号化されます。
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フィールドが存在してはなりません。
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.
chargingIdentity属性は、目的を充電するためのACホルダーを識別します。一般的には、充電アイデンティティは、ホルダーの他のアイデンティティとは異なります。例えば、保有者の会社がサービスのために充電することができます。
name id-aca-chargingIdentity OID { id-aca 3 } syntax IetfAttrSyntax values: One Attribute value only; multiple values within the IetfAttrSyntax
名前ID-ACA-chargingIdentity OID {ID-ACA 3}構文IetfAttrSyntax値：1つの属性値のみ。 IetfAttrSyntax内の複数の値
The group attribute carries information about group memberships of the AC holder.
グループ属性は、ACホルダーのグループメンバーシップに関する情報を運びます。
name id-aca-group OID { id-aca 4 } syntax IetfAttrSyntax values: One Attribute value only; multiple values within the IetfAttrSyntax
名前ID-ACA-基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のために存在する必要はありません。これはroleAuthorityフィールドがロール仕様証明書の発行者の名前を想定している場合、[X.500-2000]とは異なります。例えば、「SPYRUS」によって定義されることから、「ボルチモア」で定義された管理者の役割を区別するために、1の値を置くことができる「URN：管理者」roleAuthorityフィールド内のroleNameフィールドの値「ボルチモア」または「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
名前ID-AT-役割OID構文RoleSyntax値{72、ID-AT}：複数可
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.
組織は、セキュリティ分類の値とその意味を定義する独自のセキュリティポリシーを策定することができます。ただし、ビット列位置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中に存在することが許可されている構文を示します。オブジェクト識別子は許さ構文のそれぞれを識別します。これらの構文の1がsecurityCategoriesセット内に存在する場合、その構文に関連付けられているオブジェクト識別子はSecurityCategory.typeフィールドで運ばれます。
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] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
-- 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) module(1) selected-attribute-types(5) clearance (55) } syntax Clearance - imported from [X.501-1993] values Multiple allowed
名前{ID・アット・クリアランス} OID {関節-ISO-CCITT（2）DS（5）モジュール（1）選択された属性タイプ（5）の隙間（55）}構文クリアランス - からインポート[X.501-1993 ]値の複数可
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がTRUEに設定されたCA BOOLEANで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.
このセクションでは、すべての有効なACSが満足しなければならないルールの基本セットを記述する。いくつかの追加のチェックも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.
ホルダーは、AC検証者に認証にPKCを使用1. AC保有者のPKCを見つけなければならない、そのPKCの全体の認証パスは[PKIXPROF]に従って検証されなければなりません。セキュリティの考慮事項の項で述べたように、いくつかの他の認証方式が使用されている場合は、ACの検証が関与アイデンティティ（認証されたアイデンティティ、ホルダーフィールド）をマッピング非常に注意する必要があります。
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はタイムリーであり、このチェックは成功します。一部のアプリケーションでは、評価時間が現在の時刻と同じではないかもしれないことに注意してください。
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:
この文脈での拡張機能のサポートは、意味します：
2. Where the extension value SHOULD cause 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 which contain or lack certain attributes.
1. ACは、さらにAC検証の設定に基づいて拒否されることがあります。例えば、AC検証は、特定の属性を含むまたは欠くACSを拒否するように構成することができます。
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から属性をフィルタリングすることができます。例えば、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の有効期間は、失効情報を発行して配布するのに必要な時間未満です。そのため、短命ACSは、一般的に失効サポートを必要としません。しかし、ACSは高い値のトランザクションを有効に長寿命の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.
二つの失効スキームが定義されており、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.
証明書利用者は何の失効状態情報を利用可能にされないことを理解するように、ACSがマークされることがあります。 noRevAvail拡張はセクション4.3.6で定義され、そしてnoRevAvail拡張は、このスキームの使用を示すために、AC中に存在しなければなりません。
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.
ACSはauthorityInfoAccess拡張子または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における」スキームがサポートされる必要があります。唯一の「取り消したことがない」スキームがサポートされている場合は、noRevAvail拡張子を含まないすべてのACSは、拒絶しなければなりません。
For AC issuers, the "never revoke" scheme MUST be supported. If all ACs that will ever be issued by that AC issuer, contains 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の発行体については、「取り消すことはありません」スキームをサポートしなければなりません。これまでその交流発行人によって発行されるすべてのACSは、noRevAvail拡張が含まれている場合は、「ポインタACにおける」スキームがサポートする必要はありません。任意のACはnoRevAvail拡張が含まれていない発行することができる場合は、「ポインタACにおける」スキームをサポートしなければなりません。
An AC MUST NOT contain both a noRevAvail and a "pointer in AC".
ACはnoRevAvailと「AC内のポインタ」の両方を含めることはできません。
An AC verifier MAY use any source for AC revocation status information.
AC検証はACの失効ステータス情報の任意のソースを使用するかもしれません。
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.
このセクションでは、実装することができる機能を指定します。このプロファイルへの適合性は、これらの機能のサポートを必要としません。これらの機能が提供されている場合しかし、彼らは、以下に説明するように提供されなければなりません。
Where an AC will be carried in clear within an application protocol or where an AC contains some sensitive information like a legacy application username/password, then encryption of AC attributes MAY be needed.
どこACは、アプリケーションプロトコルまたはどこACはその後、AC属性の暗号化が必要になる場合があり、レガシーアプリケーションのユーザ名/パスワードのようないくつかの機密情報が含まれている内は明らかに運ばれます。
When a set of attributes are 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が署名する前に、属性は、所定の受信者の集合のために暗号化されています。
The AC then contains the ciphertext inside its signed data. The EnvelopedData (id-envelopedData) ContentType is used, and the content field will contain the EnvelopedData type.
ACは、その署名されたデータ内の暗号文が含まれています。 EnvelopedDataの（ID-EnvelopedDataの）のContentTypeが使用され、コンテンツフィールドはEnvelopedDataのタイプを含むであろう。
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に含まれています。一つだけencAttrs属性がAC中に存在することができます。しかし、encAttrs属性が複数の値であってもよく、その値のそれぞれが独立したの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のの暗号化コンテンツフィールドとして使用されます。 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. 2. For each attribute set which is to be encrypted: 2.1. Create an EnvelopedData structure for the data for this set of recipients. 2.2. Encode the ContentInfo containing the EnvelopedData as a value of the encAttrs attribute. 2.3. Ensure the cleartext attributes are not present in the to-be-signed AC. 3. Add the encAttrs (with its multiple values) to the AC.
1.受信者のセットごとに暗号化する属性のセットを識別します。 2.1：暗号化される各属性セット2.。受信者のこのセットのデータのためのEnvelopedData構造を作成します。 2.2。 encAttrs属性の値としてのEnvelopedDataを含むContentInfoをエンコードします。 2.3。クリアテキストの属性が-する署名ACには存在しないことを確認してください。 3. ACに（その複数の値を持つ）encAttrsを追加します。
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 same recipient is associated with more than one EnvelopedData). One approach implementers may choose, would be to merge attribute values following decryption in order to re-establish the "once only" constraint.
復号化後の同じ種類（同じオブジェクト識別子）の複数の属性が存在する可能性があることに注意してください。それは（同じ受信者が複数のEnvelopedDataのに関連付けられている場合、実際に数回）ACを明確にし、暗号化された形式の両方で同じ属性タイプが含まれている場合があります。選択することも一つの方法の実装は、「一度だけ」の制約を再確立するために、暗号解読、次の属性値をマージすることです。
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, the decryption process MUST not fail. If decryption does fail, the AC MUST 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の発行者の制御下で行わなければならないことがあります。 （複数の中間サーバとの）プロキシのチェーンのサポートも必要になることがあります。これは、ACSのチェーンを伴わないことに注意してください。
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 consists of a set of proxy information, each of which is a set of targeting information. If the verifier and the sender of the AC are both named in the same proxy set, 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 which are in one of the same proxy sets as itself.
効果は、ACホルダは任意の有効なターゲットにACを送信できることである缶自体と同じプロキシセットのいずれかにあるターゲットにのみプロキシ。
The following data structure is used to represent the targeting/proxying information.
次のデータ構造は、標的/プロキシ情報を表すために使用されます。
ProxyInfo ::= SEQUENCE OF Targets
As in the case of targeting, the targetCert CHOICE MUST NOT be used.
ターゲティングの場合のように、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.送信者の身元は、基礎となる認証サービスによって確立され、ACのホルダーフィールドと一致し、現在のサーバがプロキシ・セットのいずれか「と一致し」。セクション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.送信者の身元は、基本的な認証サービスによって確立され、「マッチ」のプロキシセットのいずれかを（それが「A」に設定呼び出し）、および現在のサーバがセット「A」の[ターゲットフィールドの一つであり、または現在のサーバがセット「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-プロキシOID {ID-PE 10}構文ProxyInfoの臨界が真でなければなりません
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は（エンティティネームを介して）同一または（baseCertificateIDを介して）PKCのいずれかにリンクされていないことが必要とされ得ます。ホルダーフィールドの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 which 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上でハッシュを使用する方法を指定します。つまり、ACSがdigestedObjectTypeためotherObjectTypes値を使用してはならない準拠です。
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. Note: This includes the AlgorithmIdentifier as well as the BIT STRING. The rules given in [PKIXPROF] for encoding keys MUST be followed. In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present.
公開鍵にACをリンクするために、ハッシュはPKCに存在するであろう、その公開鍵の表現上で計算する必要があり、具体的には、ハッシュアルゴリズムのための入力は、キーのSubjectPublicKeyInfoで表現のDER符号化でなければなりません。注：これはのAlgorithmIdentifierと同様にビット列を含んでいます。符号化キーの[PKIXPROF]で与えられた規則に従わなければなりません。この場合、digestedObjectTypeは、公開鍵でなければならないとotherObjectTypeIDフィールドが存在してはなりません。
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 which should be hashed. This can occur if DSA Dss-parms are inherited as described in section 7.3.3 of [PKIXPROF]. 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では、ハッシュ化されるべき値ではない可能性があることに留意されたいです。 【PKIXPROF]のセクション7.3.3に記載したようにDSA DSS-PARMSが継承されている場合に発生する可能性があります。この文脈においてハッシングのための適切な入力は、CAのPKCから継承されたパラメータの値が含まれ、したがって、PKCでSubjectPublicKeyInfoで存在異なっていてもよいです。
Implementations which support this feature MUST be able to handle the representations of public keys for the algorithms specified in section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present.
この機能をサポートする実装は、[PKIXPROF]のセクション7.3で指定されたアルゴリズムの公開鍵の表現を扱うことができなければなりません。この場合、digestedObjectTypeは、公開鍵でなければならないとotherObjectTypeIDフィールドが存在してはなりません。
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.
ダイジェスト介しPKCにACをリンクするために、ダイジェストは、署名値を含む、全体PKCのDERエンコーディングにわたって計算しなければなりません。この場合、digestedObjectTypeはpublicKeyCertされなければならないとotherObjectTypeIDフィールドが存在してはなりません。
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の発行者は、この属性を含むACSを発行する信頼されていますか？ 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 set 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.
permittedAttrsフィールドは、このAAのCA以下のいずれかのAC発行者は、ACSに含める許可されている属性タイプのセットを指定します。このフィールドが存在しない場合、それは何の属性タイプは、明示的に許可されていないことを意味します。
The excludedAttrs field specifies a set of attribute types that no AC issuer is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly disallowed.
excludedAttrsフィールドにはACの発行者は、ACSに含める許されない属性タイプのセットを指定します。このフィールドが存在しない場合、それは属性の型を明示的に禁止されていないことを意味します。
The permitUnSpecified field specifies how to handle attribute types which 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フィールドはpermittedAttrsまたはexcludedAttrsフィールドのいずれかに存在しない属性タイプを処理する方法を指定します。 TRUE（デフォルト）は、任意の不特定の属性タイプは、ACSで許可されていることを意味します。 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が使用される場合、AAのPKCチェーン上の次の追加のチェックがすべて有効であるとの交流のために成功しなければなりません：
1. Some CA on the ACs certificate path MUST be directly trusted to issue PKCs which precede the AC issuer in the certification path; call this CA the "AA CA".
1. ACS証明書パス上のいくつかのCAが直接証明書パスにAC発行者の前のPKCを発行する信頼されている必要があり、 "AAのCA" この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 AA CA's PKC need not contain this extension.
2. AA CAからのパス上のすべてのPKCは、ACの発行者のPKC含めへとダウン、AAControls拡張子を含まなければなりません。しかし、AA CAのPKCは、この拡張機能が含まれている必要はありません。
3. Only those attributes in the AC which 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 set of attributes following attribute decryption, and the id-aca-encAttrs type MUST also be checked.
許可されているAC 3.属性のみが、ACの発行者にAA CAからのPKCの全てにおいてAAControls拡張値の全てに従って、許可決定のために使用することができます。他のすべての属性を無視しなければなりません。このチェックは、属性の復号化を以下の属性の集合に適用されなければならない、とid-ACA-encAttrsタイプもチェックしなければなりません。
name id-pe-aaControls OID { id-pe 6 } syntax AAControls criticality MAY be TRUE
名前ID-PE-aaControls OID {ID-PE 6}構文AAControls臨界は本当かもしれません
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または失効状態を生成し、それらを装うために、攻撃者が許可されます。偽のACSおよび失効状態の存在は、システムへの信頼を損なうだろう。妥協が検出された場合は、ACの発行者によって発行されたすべてのACSは取り消さなければなりません。 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 which 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に置く必要があります保証の度合いに影響を与えます。長寿命ACSは自然に期限が切れるが、イベントは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.
名前比較規則の一貫性のないアプリケーションは、無効な対象またはACSをプロキシ、または有効なものの拒絶の受け入れをもたらすことができます。仕様の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の発行者は、保有者のPKCに識別名と同一にAC holder.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 CPSs of the CAs involved may make it clear that no such name collisions can occur.
属性証明書は、ホルダーフィールドのbaseCertificateIDコンポーネントとPKIを使用して保有者のPKCに結合されている場合は、使用中のbaseCertificateIDコンポーネントに指定したのと同じ発行者名の不正なCAを含み、この不正CAは、悪意のある第三者にPKCを発行することができます適切な保有者のPKCと同じ発行者名とシリアル番号を使用して。その後、悪意のあるパーティはACと一緒にこのPKCを使用することができます。このシナリオでは、適切に管理し、同じ名前の2つのCAは存在しないことができるようにPKIを構成することによって避けるべきです。別の代替は、ObjectDigestInfoフィールドにpublicKeyCertタイプを使用してのPKCにACSを結びつけることです。これに失敗すると、ACの検証は、潜在的な衝突が実際に発生していないことを（他の手段を使用して）を確立する必要があり、例えば、関連するCAのCPSSは、それが明確にそのような名前の衝突が発生しないことを行うことがあります。
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 AA controls 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の検証以下、唯一の発行者が問題に信頼されていることの属性が、認可の決定に使用されていることを確認しなければなりません。存在し得る他の属性は、無視しなければなりません。 AAは、PKC拡張が実装が任意である制御することを考えると、ACの検証は、他の手段によって、この情報を提供しなければなりません。構成情報は、可能性の高い代替手段です。 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.
特定のセキュリティプロトコル（例えばTLS、S / MIME）によって供給された認証およびAC保持者のアイデンティティとの間にマッピングする必要があることが多いです。認証のPKCを使用している場合、このマッピングは簡単です。しかしながら、ACSはまた、ホルダは、他の手段を使用して認証することができる環境で使用されることが想定されます。実装者は、ACホルダーに認証されたIDをマッピングするには非常に注意しなければなりません。
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. No further action by the IANA is necessary for this document or any anticipated updates.
属性と属性証明書の拡張は、オブジェクト識別子（OID）によって識別されます。このドキュメントで使用されているOIDの多くは、X.509 [X.509-2000]からコピーされます。他のOIDはIANAによって委任されたアークから割り当てました。 IANAによってそれ以上のアクションは、この文書または任意の予想されるアップデートの必要はありません。
[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[CMC]マイヤーズ、M.、劉、X.、Schaad、J.とJ.ワインスタイン、 "CMSオーバー証明書の管理のメッセージ"、RFC 2797、2000年4月。
[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure - Certificate Management Protocols", RFC 2510, March 1999.
[CMP]アダムス、C。およびS.ファレル、 "インターネットX.509公開鍵基盤 - 証明書管理プロトコル"、RFC 2510、1999年3月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、1999年6月。
[KRB] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KRB]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAP]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[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.、Ankney、R.、Malpani、A.、Galperin、S.とC.アダムス、 "X.509のインターネットの公開鍵暗号基盤 - オンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation Lists CRL Profile", RFC 3279, April 2002.
[PKIXALGS] Bassham、L.、ポーク、W.とR. Housley氏、RFC 3279、2002年4月 "インターネットX.509公開鍵基盤証明書のためのアルゴリズムと識別子と証明書失効はCRLプロファイルを一覧表示します"。
[PKIXPROF] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIXPROF] Housley氏、R.、ポーク、T、フォード、W.とソロ、D.、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ=リー、T.、Masinter L.およびM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[X.208-1988] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
【X.208-1988] CCITT勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
[X.209-88] CCITT Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
【X.209-88] CCITT勧告X. 209：抽象構文記法1（ASN.1）のためのBasic Encoding Rulesの仕様。 1988。
[X.501-88] CCITT Recommendation X.501: The Directory - Models. 1988.
[X.501-88] CCITT勧告X.501：ディレクトリ - モデル。 1988。
[X.501-1993] ITU-T Recommendation X.501 : Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X.501-1993] ITU-T勧告X.501：情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル、1993。
[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：ディレクトリ - 公開鍵と証明書の枠組みを属性。 2000
Appendix A: Object Identifiers
付録A：オブジェクト識別子
This (normative) appendix lists the new object identifiers which 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 which 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). AA's SHOULD NOT issue ACs which contain OIDs that breach these requirements.
この（規範）付録では、この仕様で定義されている新しいオブジェクト識別子を示しています。これらのいくつかは、唯一のオプション機能をサポートするために必要とされ、このプロファイルへの適合には必要ありません。本明細書の義務は、2 ^ 32未満の値を持つ円弧要素を有するのOIDのサポート（すなわち、それらは0と4,294,967,295包括間でなければなりません）及び2 ^ 31（すなわち以下2,147,483,647に等しい）未満であるべきです。これは、各円弧要素が単一の32ビット・ワード内で表現されることを可能にします。実装はまた、文字列表現は、100バイト（両端を含む）までとすることができる（セクション4.1.2、[LDAP]を参照）ここで、点線小数の長さのOIDをサポートしなければなりません。実装は最大20個の要素（包括的）でOIDを扱うことができなければなりません。 AAのこれらの要件に違反したOIDが含まれているACSを発行するべきではありません。
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) module(1)
selected-attribute-types(5) clearance (55) }
Appendix B: ASN.1 Module
付録B：ASN.1モジュール
PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-attribute-cert(12)}
PKIXAttributeCertificate {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-属性-CERT（12）}
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(1)}
GeneralName, GeneralNames, id-ce FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
PKIX1Implicit88 FROMのGeneralName、GeneralNames、ID-CE {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙-88（2）}。
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-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) module(1)
selected-attribute-types(5) clearance (55) }
-- Uncomment this if using a 1988 level ASN.1 compiler
-- 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 [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] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
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
終わり
Author's Addresses
著者のアドレス
Stephen Farrell Baltimore Technologies 39/41 Parkgate Street Dublin 8 IRELAND
スティーブン・ファレルボルチモアテクノロジーズ39/41 Parkgateのストリートダブリン8 IRELAND
EMail: stephen.farrell@baltimore.ie
メールアドレス：stephen.farrell@baltimore.ie
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousleyのRSA Laboratories社918春小山Driveハーンドン、VA 20170 USA
EMail: rhousley@rsasecurity.com
メールアドレス：rhousley@rsasecurity.com
Acknowledgements
謝辞
Russ Housley thanks the management at SPYRUS, who supported the development of this specification while he was employed at SPYRUS. Russ Housley also thanks the management at RSA Laboratories, who supported the completion of the specification after a job change.
ラスHousleyのおかげで、彼はSPYRUSで使用している間に、この仕様の開発をサポートSPYRUS、で管理。ラスHousleyも感謝ジョブ変更後仕様の完成をサポートRSA研究所で管理。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。