[要約] RFC 3281は、認証に関するインターネット属性証明書のプロファイルを定義しています。その目的は、属性証明書を使用してアクセス制御を行うための標準化とガイドラインを提供することです。
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.
Copyright（c）The Internet Society（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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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とACを常に混乱させます。類推は区別を明確にするかもしれません。PKCはパスポートのようなものと見なすことができます。ホルダーを識別し、長期にわたって持続する傾向があり、取得するのに些細なことではありません。ACはエントリビザのようなものです。通常、別の当局によって発行され、長い間持続しません。通常、エントリービザを取得するにはパスポートを提示する必要があるため、ビザを取得することはより簡単なプロセスになる可能性があります。
Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.
許可情報は、PKC拡張機能に配置するか、別の属性証明書（AC）に配置する場合があります。PKCSへの承認情報の配置は、通常、2つの理由で望ましくありません。第一に、認可情報は、多くの場合、アイデンティティと公開鍵の拘束力と同じ寿命を持っていません。許可情報が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はこのバインディングを提供します。これは、単にデジタルで署名された（または認定された）IDと一連の属性です。
An AC may be used with various security services, including access control, data origin authentication, and non-repudiation.
ACは、アクセス制御、データ起源認証、非控除など、さまざまなセキュリティサービスで使用できます。
PKCs can provide an identity to access control decision functions. However, in many contexts the identity is not the criterion that is used for access control decisions, rather the role or group-membership of the accessor is the criterion used. Such access control schemes are called role-based access control.
PKCは、制御決定機能にアクセスするためのIDを提供できます。ただし、多くのコンテキストでは、アイデンティティはアクセス制御の決定に使用される基準ではなく、アクセサの役割またはグループメンバーシップが使用される基準です。このようなアクセス制御スキームは、ロールベースのアクセス制御と呼ばれます。
When making an access control decision based on an AC, an access control decision function may need to ensure that the appropriate AC holder is the entity that has requested access. One way in which the linkage between the request or identity and the AC can be achieved is the inclusion of a reference to a PKC within the AC and the use of the private key corresponding to the PKC for authentication within the access request.
ACに基づいてアクセス制御決定を下す場合、アクセス制御決定機能は、適切なACホルダーがアクセスを要求したエンティティであることを確認する必要があります。リクエストまたはIDとACの間のリンクを達成できる1つの方法は、AC内のPKCへの参照を含めることと、アクセス要求内の認証のためにPKCに対応する秘密鍵の使用です。
ACs may also be used in the context of a data origin authentication service and a non-repudiation service. In these contexts, the attributes contained in the AC provide additional information about the signing entity. This information can be used to make sure that the entity is authorized to sign the data. This kind of checking depends either on the context in which the data is exchanged or on the data that has been digitally signed.
ACSは、Data Origin Authentication Serviceと非repudiationサービスのコンテキストでも使用できます。これらのコンテキストでは、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 Standard [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.
ACSの順序付けられたシーケンスを使用して、特権アッサーの特権の信頼性を検証できます。このようにして、ACSのチェーンまたはパスを使用して、承認を委任することができます。
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チェーンに関連する管理と処理は複雑であり、今日のインターネットでのACSの使用は非常に限られているため、この仕様はACチェーンの使用を推奨していません。その他の（将来の）仕様は、ACチェーンの使用に対処する場合があります。この仕様では、特定の属性セットに対して1つの当局がすべてのACSを発行する単純なケースを扱います。ただし、この単純化は、いくつかの異なる当局の使用を排除するものではなく、それぞれが異なる属性セットを管理しています。たとえば、グループメンバーシップは、ある当局によって発行された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の処理が次々と必要になる場合があります。ただし、ACの検証には、[PKIXPROF]で指定されているように、PKCのチェーンの検証が必要になる場合があります。
As discussed above, ACs provide a mechanism to securely provide authorization information to, for example, access control decision functions. However, there are a number of possible communication paths for ACs.
上記で説明したように、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
This AC profile meets the following requirements.
このACプロファイルは、次の要件を満たしています。
Time/Validity requirements:
時間/妥当性の要件：
1. Support for short-lived as well as long-lived ACs. Typical short-lived validity periods might be measured in hours, as opposed to months for PKCs. Short validity periods allow ACs to be useful without a revocation mechanism.
1. 短命および長命のACSのサポート。PKCの数か月とは対照的に、典型的な短命の妥当性の期間は数時間で測定される場合があります。短い妥当性期間により、取り消しメカニズムなしにACSが役立つことができます。
Attribute Types:
属性タイプ：
2. Issuers of ACs should be able to define their own attribute types for use within closed domains.
2. ACSの発行者は、閉じたドメイン内で使用する独自の属性タイプを定義できるはずです。
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. ACS内に含めることができるいくつかの標準属性タイプを定義する必要があります。例には、「アクセスアイデンティティ」、「グループ」、「役割」、「クリアランス」、「監査アイデンティティ」、「充電アイデンティティ」が含まれます。
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検証者が異なるドメイン内の同じ属性の使用を区別できるようにする方法で定義する必要があります。たとえば、ボルチモアによって定義された「管理者グループ」とスピルスで定義されている「管理者グループ」は、簡単に区別する必要があります。
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. ACを1つ、または少数のサーバーで「ターゲット」することができるはずです。これは、信頼できる非ターゲットサーバーが認可決定のためにACを拒否することを意味します。
Push vs. Pull
プッシュvs.プル
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は、クライアントがサーバーに「プッシュ」するか、オンラインAC発行者を含むリポジトリまたはその他のネットワークサービスからサーバーによって「プル」できるように定義する必要があります。
ACs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability and limited special purpose requirements. In particular, the emphasis will be on supporting the use of attribute certificates for informal Internet electronic mail, IPSec, and WWW applications.
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（または後の）バージョンを使用していますが、このドキュメントでは、PKCS [PKIXPROF]で行われているように、1988 ASN.1構文を使用しています。いずれかのASN.1バージョンからのエンコードされた証明書と拡張機能は、少し同一です。
Where maximum lengths for fields are specified, these lengths refer to the DER encoding and do not include the ASN.1 tag or length fields.
フィールドの最大長が指定されている場合、これらの長さはderエンコーディングを指し、asn.1タグまたは長さフィールドは含まれません。
Conforming implementations MUST support the profile specified in this section.
適合実装は、このセクションで指定されたプロファイルをサポートする必要があります。
X.509 contains the definition of an AC given below. All types that are not defined in this document can be found in [PKIXPROF].
X.509には、以下のACの定義が含まれています。このドキュメントで定義されていないすべてのタイプは、[pkixprof]にあります。
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion -- version is v2,
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the holder,
-- for example, an executable
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST NOT
-- be present in this profile
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
Although the Attribute syntax is defined in [PKIXPROF], we repeat the definition here for convenience.
属性の構文は[pkixprof]で定義されていますが、ここで定義を繰り返して、便利にします。
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
Implementers should note that the DER encoding (see [X.509- 1988],[X.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.509-1988]、[x.208-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は素晴らしい柔軟性を提供します。この柔軟性にもかかわらず、相互運用性を実現するために、このプロファイルは一般名の使用に制約を課します。
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、およびiPaddressオプションをサポートできる必要があります。これは、[PKIXPROF]（主にセクション4.2.1.7）の一般名の要件と互換性があります。
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options.
適合の実装は、X400Address、EdipartyName、または登録済みオプションを使用してはなりません。
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.
適合の実装は、Internet Standardsで定義されている名前フォームを伝えるために、otherNameオプションを使用する場合があります。たとえば、Kerberos [KRB]形式名は、Kerberos 5の主名OIDと領域とプリンシパル名のシーケンスを使用して、他の名前にエンコードできます。
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 Standard [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.
ホルダーフィールドは、3つの異なる（オプションの）構文を許可するシーケンスです：BasecertificateId、EntityName、およびObjectDigestinfo。1つのオプションのみが存在する場合、ホルダーフィールドの意味は明確です。ただし、複数のオプションが使用されている場合、[X.509-2000]から正しい位置が明確ではないため、どのオプションが「規範的」であるかについて混乱の可能性があります。仕様では、任意のACで使用されるオプションの1つのみが推奨されます。
For any environment where the AC is passed in an authenticated message or session and where the authentication is based on the use of an X.509 PKC, the holder field SHOULD use the baseCertificateID.
ACが認証されたメッセージまたはセッションで渡され、認証がX.509 PKCの使用に基づいている環境の場合、ホルダーフィールドは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発行者には、DirectoryNameフィールドのholder.basecertificateid.issuerコンストラクトの単一値として存在するものである空白のない著名な名前が必要です。AC Holder.BaseCertificateId.Issueruidフィールドは、所有者のPKCに発行型フィールドが含まれている場合にのみ使用する必要があります。AC Holder.BaseCertificateId.IssueruidとPKC発行型フィールドの両方が存在する場合、両方のフィールドに同じ値が存在する必要があります。したがって、BaseCertificateIDは、PKC発行者フィールドに空白のない著名な名前値が含まれていることを義務付けるPKCプロファイル（[PKIXPROF]など）でのみ使用可能です。
Note: An empty distinguished name is a distinguished name where the SEQUENCE OF relative distinguished names is of zero length. In a DER encoding, this has the value '3000'H.
注：空の著名な名前は、相対的な著名な名前のシーケンスがゼロの長さの著名な名前です。derエンコーディングでは、値 '3000'hがあります。
If the holder field uses the entityName option and the underlying authentication is based on a PKC, the entityName MUST be the same as the PKC subject field or one of the values of the PKC subjectAltName field extension (if present). Note that [PKIXPROF] mandates that the subjectAltName extension be present if the PKC subject is an empty distinguished name. See the security considerations section which mentions some name collision problems that may arise when using the entityName option.
ホルダーフィールドがEntityNameオプションを使用し、基礎となる認証がPKCに基づいている場合、EntityNameはPKCサブジェクトフィールドまたはPKC SecumentNameフィールド拡張の値の1つと同じでなければなりません（存在する場合）。[PKIXPROF]は、PKCの被験者が空の著名な名前である場合、subjectaltname拡張機能が存在することを義務付けていることに注意してください。EntityNameオプションを使用するときに発生する可能性のある名前の衝突問題について言及するセキュリティに関する考慮事項セクションを参照してください。
In any other case where the holder field uses the entityName option, only one name SHOULD be present.
ホルダーフィールドがentityNameオプションを使用する他の場合、1つの名前のみが存在する必要があります。
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は、v2Form選択を使用する必要があります。これには、ISSUENMAMEに1つの一般名のみが含まれている必要があります。これは、すべての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検証剤がどの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]で定義されている署名アルゴリズムの1つでなければなりません。実装の適合は、[pkixalgs]で指定されたアルゴリズムステートメントに署名するすべてのマスト/subs/suld/sult/mayを尊重する必要があります。
For any conforming AC, the issuer/serialNumber pair MUST form a unique combination, even if ACs are very short-lived.
適合したACの場合、ACSが非常に短命であっても、発行者/SerialNumberペアは一意の組み合わせを形成する必要があります。
AC issuers MUST force the serialNumber to be a positive integer, that is, the sign bit in the DER encoding of the INTEGER value MUST be zero - this can be done by adding a leading (leftmost) '00'H octet if necessary. This removes a potential ambiguity in mapping between a string of octets and an integer value.
AC発行者は、SerialNumberを正の整数に強制する必要があります。つまり、整数値のderエンコードのサインビットはゼロでなければなりません。これにより、一連のオクテットと整数値の間のマッピングにおける潜在的な曖昧さが削除されます。
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オクテットより長いシリアルナンバーの値を処理できる必要があります。コンフォーマントACSには、20オクテットを超えるシリアルナンバー値を含めてはなりません。
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.
attrcertalidityidityperiod（a.k.a。の有効性）フィールドは、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.
一般化された時間型、一般化された時間は、時間の可変精度表現の標準ASN.1タイプです。一般化された時間フィールドには、オプションで、ローカルタイムゾーンとグリニッジ平均時間の間の時間差の表現を含めることができます。
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.
このプロファイルの目的のために、一般化された時間の値は、秒数がゼロであっても、調整された普遍的時間（UTC）（グリニッジ平均時間またはズールーとも呼ばれます）で表現する必要があり、秒を含める必要があります（つまり、yyyymmddhhmssz）。一般化された時間値は、分数秒を含めてはなりません。
(Note: this is the same as specified in [PKIXPROF], section 4.1.2.5.2.)
（注：これは、[pkixprof]、セクション4.1.2.5.2で指定されていると同じです。）
AC users MUST be able to handle an AC which, at the time of processing, has parts of its validity period or all its validity period in the past or in the future (a post-dated AC). This is valid for some applications, such as backup.
ACユーザーは、処理時に、過去または将来の有効期間またはすべての有効期間の一部（日付のAC）を持っているACを処理できる必要があります。これは、バックアップなどの一部のアプリケーションで有効です。
The attributes field gives information about the AC holder. When the AC is used for authorization, this will often contain a set of privileges.
属性フィールドは、ACホルダーに関する情報を提供します。ACが許可に使用される場合、これには多くの場合、一連の特権が含まれます。
The attributes field contains a SEQUENCE OF Attribute. Each Attribute 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の場合、シーケンス内の各属性オブジェクト識別子は一意でなければなりません。つまり、各属性の1つのインスタンスのみが単一の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]は、このフィールドはCASに適合して使用すべきではないが、アプリケーションがフィールドを含む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には監査ID拡張機能が含まれる場合があります。理想的には、AC発行者の協力なしに、ACホルダーの身元を監査IDの価値から導き出すことは実行不可能です。
The value of the audit identity, along with the AC issuer/serial, SHOULD then be used for audit/logging purposes. If the value of the audit identity is suitably chosen, a server/service administrator can use audit trails to track the behavior of an AC holder without being able to identify the AC holder.
監査IDの価値は、AC発行者/シリアルとともに、監査/ロギングの目的で使用する必要があります。監査IDの値が適切に選択されている場合、サーバー/サービス管理者は監査証跡を使用して、ACホルダーを識別できずにACホルダーの動作を追跡できます。
The server/service administrator in combination with the AC issuer MUST be able to identify the AC holder in cases where misbehavior is detected. This means that the AC issuer MUST be able to determine the actual identity of the AC holder from the audit identity.
AC発行者と組み合わせたサーバー/サービス管理者は、不正行為が検出された場合にACホルダーを識別できる必要があります。これは、AC発行者が監査IDからACホルダーの実際の身元を決定できる必要があることを意味します。
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ホルダーのアイデンティティがワイヤでビットに露出します。そのような場合、不透明な監査IDはAC Anonymousを使用しません。それは単に、次の監査証跡に識別情報が含まれていないことを保証します。
The value of an audit identity MUST be longer than zero octets. The value of an audit identity MUST NOT be longer than 20 octets.
監査IDの値は、ゼロオクテットよりも長くなければなりません。監査IDの値は、20オクテットを超えてはなりません。
name id-pe-ac-auditIdentity OID { id-pe 4 } syntax OCTET STRING criticality MUST be TRUE
名前id-pe-ac-auditidentity oid {id-pe 4}構文octet文字
To target an AC, the target information extension, imported from [X.509-2000], MAY be used to specify a number of servers/services. The intent is that the AC SHOULD only be usable at the specified servers/services. An (honest) AC verifier who is not amongst the named servers/services MUST reject the AC.
ACをターゲットにするために、[X.509-2000]からインポートされたターゲット情報拡張機能を使用して、多くのサーバー/サービスを指定できます。意図は、ACが指定されたサーバー/サービスでのみ使用可能であることです。名前付きサーバー/サービスの中にいない（正直な）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.
ターゲットチェックは、現在のサーバー（受信者）がターゲットシーケンスのターゲット名フィールドの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は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発行者の実装の適合は、1つの「ターゲット」要素のみを生成する必要があります。ACユーザーの確認は、「ターゲットのシーケンス」を受け入れることができなければなりません。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.
[pkixprof]でプロファイルされているauthorideyidentifier拡張機能を使用して、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の選択を使用したACは、紹介された証明書のキーに明示的にリンクされているため、authoritykeyidentifier拡張機能を必要としません。ただし、このプロファイルが述べているように（セクション4.2.3で）、ACSは発行者の選択でV2Formを使用する必要がありますが、この複製は発生しません。
name id-ce-authorityKeyIdentifier OID { id-ce 35 } syntax AuthorityKeyIdentifier criticality MUST be FALSE
名前id-ce-authoritykeyidentifier oid {id-ce 35}構文authorideyidentifier臨界性は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.
[PKIXPROF]で定義されているauthorInformationAccess拡張機能は、AC検証剤がACの取り消しステータスをチェックするのを支援するために使用できます。ACチェーンは予想されていないため、ID-AD-Caissuers AccessMethodのサポートはこのプロファイルでは必要ありません。
The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the 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.
アクセスロケーションにはURIが含まれている必要があり、URIにはOCSPレスポンダーの位置を指定するHTTP URL [URL]を含める必要があります。もちろん、AC発行者はこの場所でOCSP Responderを維持する必要があります。
name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE
名前id-ce-authorityinfoacses oid {id-pe 1}構文authoridinfoaccessyntax臨界性はfalseでなければなりません
The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. See section 6 for details on revocation.
[pkixprof]でプロファイルされているCrldistributionPoints拡張は、ACのVerifierが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
name 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 encoding）臨界性はfalseでなければなりません
Some of the attribute types defined below make use of the IetfAttrSyntax type, also defined below. The reasons for using this type are:
以下に定義されている属性タイプの一部は、以下に定義するIETFATTRSYNTAXタイプを使用します。このタイプを使用する理由は次のとおりです。
1. It allows a separation between the AC issuer and the attribute policy authority. This is useful for situations where a single policy authority (e.g. an organization) allocates attribute values, but where multiple AC issuers are deployed for performance or other reasons.
1. これにより、AC発行者と属性政策機関の分離が可能になります。これは、単一の政策機関（組織など）が属性値を割り当てる状況に役立ちますが、複数のAC発行者がパフォーマンスまたはその他の理由で展開される場合に役立ちます。
2. The syntaxes allowed for values are restricted to OCTET STRING, OBJECT IDENTIFIER, and UTF8String, which significantly reduces the complexity associated with matching more general syntaxes. All multi-valued attributes using this syntax are restricted so that each value MUST use the same choice of value syntax. For example, AC issuers must not use one value with an oid and a second value with a string.
2. 値に許可された構文は、Octet String、Object Identifier、およびUTF8Stringに制限されており、より一般的な構文の一致に関連する複雑さを大幅に削減します。この構文を使用するすべての多値属性は制限されているため、各値は同じ選択の構文を使用する必要があります。たとえば、AC発行者は、OIDで1つの値を使用し、文字列で2番目の値を使用してはなりません。
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
In the descriptions below, each attribute type is either tagged "Multiple Allowed" or "One Attribute value only; multiple values within the IetfAttrSyntax". This refers to the SET OF AttributeValues; the AttributeType still only occurs once, as specified in section 4.2.7.
以下の説明では、各属性タイプは「複数の許可」または「1つの属性値のみ、IETFATTRSYNTAX内の複数の値」とタグ付けされています。これは、一連の属性を指します。属性は、セクション4.2.7で指定されているように、まだ1回しか発生しません。
The SvceAuthInfo attribute identifies the AC holder to the server/service by a name, and the attribute MAY include optional service specific authentication information. Typically this will contain a username/password pair for a "legacy" application.
SVCEAUTHINFO属性は、ACホルダーをServer/Serviceの名前で識別し、属性にはオプションのサービス固有の認証情報が含まれる場合があります。通常、これには「レガシー」アプリケーション用のユーザー名/パスワードペアが含まれます。
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
name 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ホルダーに関する情報を提供するために使用することを目的としています。。これは、上記4.4.1で説明されているSVCeauthinfo属性を意図したものとは異なる使用であることに注意してください。
name id-aca-accessIdentity OID { id-aca 2 } syntax SvceAuthInfo values: Multiple allowed
名前id-aca-accessidentity oid {id-aca 2} syntax 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.
充電Identity属性は、ACホルダーを充電目的で識別します。一般に、充電アイデンティティは、所有者の他のアイデンティティとは異なります。たとえば、保有者の会社はサービスに対して請求される場合があります。
name id-aca-chargingIdentity OID { id-aca 3 } syntax IetfAttrSyntax values: One Attribute value only; multiple values within the IetfAttrSyntax
name id-aca-chargingidentity oid {id-aca 3}構文ietfattrsyntax値：1つの属性値のみ。ietfattrsyntax内の複数の値
The group attribute carries information about group memberships of the AC holder.
グループ属性には、ACホルダーのグループメンバーシップに関する情報が含まれています。
name id-aca-group OID { id-aca 4 } syntax IetfAttrSyntax values: One Attribute value only; multiple values within the IetfAttrSyntax
name id-aca-group oid {id-aca 4}構文ietfattrsyntax値：1つの属性値のみ。ietfattrsyntax内の複数の値
The role attribute, specified in [X.509-2000], carries information about role allocations of the AC holder.
[x.509-2000]で指定された役割属性は、ACホルダーの役割割り当てに関する情報を伝えます。
The syntax used for this attribute is:
この属性に使用される構文は次のとおりです。
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
The roleAuthority field MAY be used to specify the issuing authority for the role specification certificate. There is no requirement that a role specification certificate necessarily exists for the roleAuthority. This differs from [X.500-2000], where the roleAuthority field is assumed to name the issuer of a role specification certificate. For example, to distinguish the administrator role as defined by "Baltimore" from that defined by "SPYRUS", one could put the value "urn:administrator" in the roleName field and the value "Baltimore" or "SPYRUS" in the roleAuthority field.
RoleAuthorityフィールドを使用して、役割仕様証明書の発行機関を指定できます。役割仕様証明書が必ずしもロールートリティに存在するという要件はありません。これは[x.500-2000]とは異なり、ロールオーソリティフィールドは、役割仕様証明書の発行者に名前を付けると想定されています。たとえば、「ボルチモア」によって定義された管理者の役割を「スピルス」によって定義された役割を区別するために、ロレナムフィールドに値「urn：管理者」を置き、ロールオーサティフィールドの値「ボルチモア」または「スピルス」を置くことができます。。
The roleName field MUST be present, and roleName MUST use the uniformResourceIdentifier CHOICE of the GeneralName.
Rolenameフィールドが存在する必要があり、RolenameはGeneralNameのUniformResourceIdentifier選択を使用する必要があります。
name id-at-role OID { id-at 72 } syntax RoleSyntax values: Multiple allowed
名前id-at-role oid {id-at 72} syntax roleyntax値：複数の許可
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は、クラスリストとセキュリティカテゴリのフィールドのセマンティクスを示しています。
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]で指定されているクラスリストフィールドが含まれています。追加のセキュリティ分類値、および分類階層におけるそれらの位置は、セキュリティポリシーによってローカルの問題または二国間協定によって定義される場合があります。基本的なセキュリティ分類階層は、昇順で、マークされていない、分類されていない、制限、機密、秘密、および秘密です。
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セットに存在する場合、その構文に関連付けられたオブジェクト識別子は、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
The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage extension in the PKC MUST NOT explicitly indicate that the AC issuer's public key cannot be used to validate a digital signature. In order to avoid confusion regarding serial numbers and revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a basicConstraints extension with the cA BOOLEAN set to TRUE.
AC発行者のPKCは[PKIXPROF]に準拠する必要があり、PKCのKeyUSAGE拡張は、AC発行者の公開キーを使用してデジタル署名を検証できないことを明示的に示してはなりません。シリアル番号や取り消しに関する混乱を避けるために、AC発行者もPKC発行者であってはなりません。つまり、AC発行者もCAになることはできません。したがって、AC発行者のPKCには、Ca BooleanがTrueに設定されたBasicConstraints拡張機能を持たないはずです。
This section describes a basic set of rules that all valid ACs MUST satisfy. Some additional checks are also described which AC verifiers MAY choose to implement.
このセクションでは、すべての有効な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.
1. ホルダーがPKCを使用してAC検証剤に認証する場合、ACホルダーのPKCを見つける必要があり、そのPKCの認証パス全体を[PKIXPROF]に従って検証する必要があります。セキュリティ上の考慮事項セクションで述べたように、他の認証スキームが使用されている場合、AC検証剤は、関係するID（認証されたID、保有者フィールド）を非常に慎重にマッピングする必要があります。
2. The AC signature must be cryptographically correct, and the AC issuer's entire PKC certification path MUST be verified in accordance with [PKIXPROF].
2. ACの署名は暗号化的に正しいものでなければならず、AC発行者のPKC認定パス全体を[PKIXPROF]に従って検証する必要があります。
3. The AC issuer's PKC MUST also conform to the profile specified in section 4.5 above.
3. AC発行者のPKCは、上記のセクション4.5で指定されたプロファイルにも準拠する必要があります。
4. The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise).
4. AC発行者は、AC発行者として直接信頼されなければなりません（構成またはその他）。
5. The time for which the AC is being evaluated MUST be within the AC validity. If the evaluation time is equal to either notBeforeTime or notAfterTime, then the AC is timely and this check succeeds. Note that in some applications, the evaluation time MAY not be the same as the current time.
5. ACが評価されている時間は、ACの妥当性内でなければなりません。評価時間が存在しないかノートタイムに等しい場合、ACはタイムリーで、このチェックは成功します。一部のアプリケーションでは、評価時間が現在の時間と同じではない場合があることに注意してください。
6. The AC targeting check MUST pass as specified in section 4.3.2.
6. ACターゲティングチェックは、セクション4.3.2で指定されているとおりに渡す必要があります。
7. If the AC contains an unsupported critical extension, the AC MUST be rejected.
7. ACにサポートされていない批判的拡張が含まれている場合、ACを拒否する必要があります。
Support for an extension in this context means:
このコンテキストでの拡張機能のサポートは、次のことを意味します。
1. The AC verifier MUST be able to parse the extension value.
1. AC検証剤は、拡張値を解析できる必要があります。
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が高価値トランザクションを有効にする長寿命のACSおよび環境では、取り消しサポートが必要になる場合があります。
Two revocation schemes are defined, and the AC issuer should elect the one that is best suited to the environment in which the AC will be employed.
2つの取り消しスキームが定義されており、AC発行者はACが採用される環境に最適な発行者を選択する必要があります。
"Never revoke" scheme:
「決して取り消さない」スキーム：
ACs may be marked so that the relying party understands that no revocation status information will be made available. The noRevAvail extension is defined in section 4.3.6, and the noRevAvail extension MUST be present in the AC to indicate use of this scheme.
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は、authoridinfoaccess拡張機能または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ユーザーの場合、「Never Reboke」スキームをサポートする必要があり、「ACのポインター」スキームをサポートする必要があります。「Never evoke」スキームのみがサポートされている場合、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発行者の場合、「決して取り消さない」スキームをサポートする必要があります。そのAC発行者によって発行されるすべてのACSがNoreVavail拡張機能を含む場合、「ACのポインター」スキームをサポートする必要はありません。Norevavail拡張機能を含まないACを発行できる場合、「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内で暗号化する場合、暗号化メッセージ構文[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.
ciphertextは、encattrs属性の値としてACに含まれています。ACに存在できるEncattrs属性は1つだけです。ただし、Encattrs属性は多値である場合があり、その各値には独立した封筒が含まれます。
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エンコードは、封筒の暗号化されたコンテンツフィールドとして使用されます。derエンコーディングは、オクテット弦に埋め込む必要があります。
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からCiphertextをコピーすることを防ぎます（対応するプレーンテキストを知らずに）。
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.暗号化される各属性セットについて：2.1。この一連の受信者のデータの封筒構造を作成します。2.2。EnvelopedDataを含むcontentinfoをEncattrs属性の値としてエンコードします。2.3。ClearText属性が、署名されたACに存在しないことを確認してください。3. encattrs（複数の値を持つ）をACに追加します。
Note that there may be more than one attribute of the same type (the same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain the same attribute type both in clear and in encrypted form (and indeed several times if the 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.
復号化後、同じタイプ（同じオブジェクト識別子）の複数の属性がある場合があることに注意してください。つまり、ACは、クリアフォームと暗号化された形式の両方で同じ属性タイプを含む場合があります（実際、同じ受信者が複数の封筒に関連付けられている場合は数回）。実装者が選択できるアプローチの1つは、「一度のみ」制約を再確立するために、復号化後の属性値をマージすることです。
name id-aca-encAttrs OID { id-aca 6} Syntax ContentInfo values Multiple Allowed
名前id-aca-encattrs oid {id-aca 6}構文contentinfo値倍数
If an AC contains attributes, apparently encrypted for the AC verifier, 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の選択を使用してはなりません。
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. 基礎となる認証サービスによって確立された送信者の識別は、プロキシセットの1つ（set "a"と呼ばれます）の1つを「一致させる」、現在のサーバーはセット「a」のターゲット名フィールドの1つまたは現在のサーバーは、セット「A」のターゲットグループフィールドの1つのメンバーです。
When an AC is proxied more than once, a number of targets will be on the path from the original client, which is normally, but not always, the AC holder. In such cases, prevention of AC "stealing" requires that the AC verifier MUST check that all targets on the path are members of the same proxy set. It is the responsibility of the AC-using protocol to ensure that a trustworthy list of targets on the path is available to the AC verifier.
ACが複数回プロキシ化されると、多くのターゲットが元のクライアントからパス上にあります。これは通常、常にではありませんが、ACホルダーです。そのような場合、ACの「盗み」の防止では、AC検証者がパス上のすべてのターゲットが同じプロキシセットのメンバーであることを確認する必要があります。AC検証器がパス上のターゲットの信頼できるリストが利用できるようにすることは、AC使用プロトコルの責任です。
name id-pe-ac-proxying OID { id-pe 10 } syntax ProxyInfo criticality MUST be TRUE
名前id-pe-ac-proxying oid {id-pe 10} syntax 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がID（EntityName経由）またはPKC（BasecertificateID経由）のいずれかにリンクされないことが必要になる場合があります。ホルダーフィールドでのObjectDigestinfoの選択により、この要件をサポートできます。
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をオブジェクトにリンクすることです。たとえば、これにより、名前ではなくパブリックキーにリンクされているACSの生産が可能になります。また、Javaクラスなどの実行可能なオブジェクトに関連付けられた特権を含むACSの生産も可能にします。ただし、このプロファイルは、公開キーまたは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を公開キーにリンクするには、HashをPKCに存在するその公開キーの表現で計算する必要があります。特に、ハッシュアルゴリズムの入力は、キーの件名のderエンコードでなければなりません。注：これには、Algorithmidentifierとビット文字列が含まれます。エンコードキーの[pkixprof]に与えられたルールに従う必要があります。この場合、DigestedObjectTypeはpublicKeyである必要があり、その他のObjectTypeIDフィールドが存在してはなりません。
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からの件名PublicKeyInfoはハッシュする値ではない可能性があることに注意してください。これは、[PKIXPROF]のセクション7.3.3で説明されているように、DSA DSS-PARMSが継承されている場合に発生する可能性があります。このコンテキストでのハッシュの正しい入力には、CAのPKCから継承されたパラメーターの値が含まれ、したがってPKCに存在する件名PublicKeyInfoと異なる場合があります。
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はpublicKeyである必要があり、その他のObjectTypeIDフィールドが存在してはなりません。
In order to link an AC to a PKC via a digest, the digest MUST be calculated over the DER encoding of the entire PKC, including the signature value. In this case the digestedObjectType MUST be publicKeyCert and the otherObjectTypeID field MUST NOT be present.
ダイジェストを介してACをPKCにリンクするには、署名値を含むPKC全体のderエンコードでダイジェストを計算する必要があります。この場合、DigestedObjectTypeはpublicKeycertでなければならず、他のObjectTypeIDフィールドが存在してはなりません。
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.
PermitedAttrsフィールドは、この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.
excredattrsフィールドは、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.
PmitunSpecified Fieldは、PermitedAttrsまたはExcrudedAttrsフィールドのいずれにも存在しない属性タイプを処理する方法を指定します。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チェーンの次の追加チェックはすべて、ACが有効であるために成功する必要があります。
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」と呼びます。
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からAC発行者のPKCまでのパス上のすべての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.
3. AA CAからAC発行者までのすべてのPKCのすべてのAACONTROLS拡張値に従って、許可されているACのこれらの属性のみが、許可決定に使用できます。他のすべての属性は無視する必要があります。このチェックは、属性の復号化に続いて属性のセットに適用する必要があり、ID-ACA-Encattrsタイプもチェックする必要があります。
name id-pe-aaControls OID { id-pe 6 } syntax AAControls criticality MAY be TRUE
名前id-pe-aacontrols oid {id-pe 6} syntax 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発行者がプライベートキーを保護できなかった場合、攻撃者が攻撃者を装って、誤ったACSまたは取り消しステータスを生成する可能性があります。偽の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に配置されるべき保証の程度に影響します。長寿命のACは自然に期限切れになりますが、ACホルダーと属性の間の結合を無効にする自然な寿命の間にイベントが発生する可能性があります。失効ステータスが早すぎる場合、または利用できない場合、バインディングに関連する保証は明らかに減少します。
The binding between an AC holder and attributes cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of an AC. AC issuers are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
ACホルダーと属性の間のバインディングは、署名を生成するために使用される暗号化モジュールの実装とアルゴリズムよりも強くなることはできません。キーの長さが短いまたは弱いハッシュアルゴリズムは、ACのユーティリティを制限します。AC発行者は、暗号学の進歩に注意して、強力な暗号化技術を採用できるようにすることをお勧めします。
Inconsistent application of name comparison rules may result in acceptance of invalid targeted or proxied ACs, or rejection of valid ones. The X.500 series of specifications defines rules for comparing distinguished names. These rules require comparison of strings without regard to case, character set, multi-character white space substrings, or leading and trailing white space. This specification and [PKIXPROF] relaxes these requirements, requiring support for binary comparison at a minimum.
名前の比較ルールの一貫性のない適用は、無効なターゲットまたはプロキシのACSの受け入れ、または有効なACの拒否をもたらす可能性があります。X.500の一連の仕様は、識別名を比較するためのルールを定義しています。これらのルールでは、ケース、キャラクターセット、マルチキャラクターホワイトスペースサブストリング、またはリーディングおよびトレーリングホワイトスペースに関係なく、文字列の比較が必要です。この仕様と[PKIXPROF]はこれらの要件を緩和し、少なくともバイナリ比較をサポートする必要があります。
AC issuers MUST encode the distinguished name in the AC holder.entityName field identically to the distinguished name in the holder's PKC. If different encodings are used, implementations of this specification may fail to recognize that the AC and PKC belong to the same entity.
AC発行者は、AC Holder.EntityNameフィールドの著名な名前を、所有者のPKCの著名な名前と同じようにエンコードする必要があります。異なるエンコーディングが使用されている場合、この仕様の実装は、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.
属性証明書がホルダーフィールドのベースカルチフィクタティドコンポーネントと使用中のPKIを使用して所有者のPKCに結び付けられている場合、ベースコンチェンテーションコンポーネントで指定された同じ発行者名を持つ不正なCAが含まれています。同じ発行者名とシリアル番号を適切な所有者のPKCと使用します。その後、悪意のあるパーティーは、このPKCをACと併用することができます。このシナリオは、PKIを適切に管理および構成して、同じ名前の2つのCAが存在できないように回避する必要があります。もう1つの選択肢は、ObjectDigestInfoフィールドのPublicKeyCertタイプを使用してACSをPKCに結び付けることです。これに失敗すると、AC検証は（他の手段を使用して）潜在的な衝突が実際に発生しないことを確立する必要があります。たとえば、関係するCAのCPSは、そのような名前の衝突が発生しないことを明らかにする可能性があります。
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present MUST be ignored. Given that the 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ホルダーのIDとの間にマッピングする要件があります。認証がPKCを使用する場合、このマッピングは簡単です。ただし、ACSは、他の手段を使用してホルダーが認証される可能性がある環境でも使用されることが想定されています。実装者は、認証されたアイデンティティをACホルダーにマッピングする際に非常に注意する必要があります。
Attributes and attribute certificate extensions are identified by object identifiers (OIDs). Many of the OIDs used in this document are copied from X.509 [X.509-2000]. Other OIDs were assigned from an arc delegated by the IANA. 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] Myers、M.、Liu、X.、Schaad、J。、およびJ. Weinstein、「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] Adams、C。and S. Farrell、「Internet 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] Hoffman、P。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[KRB] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KRB] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAP] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャ - オンライン証明書ステータスプロトコル」、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.、Polk、W。and R. Housley、「インターネットのアルゴリズムと識別子X.509公開キーインフラストラクチャ証明書と証明書の取り消しリストCRLプロファイル」、RFC 3279、2002年4月。
[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.、Polk、T、Ford、W。およびSolo、D。、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee、T.、Masinter L.およびM. McCahill、「Uniform Resource Locators（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）の基本エンコーディングルールの仕様。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未満（つまり、0〜4,294,967,295が包括的でなければならない）が2^31未満である（つまり2,147,483,647以下）が必要なARC要素を持つOIDSのサポートが義務付けられています。これにより、各ARC要素を単一の32ビットワード内で表すことができます。また、実装は、点線の小数点の長さ（[LDAP]を参照）、セクション4.1.2を参照）の文字列表現を最大100バイト（包括的）でサポートする必要があります。実装は、最大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)}
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)} ;
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パークゲートストリートダブリン8アイルランド
EMail: stephen.farrell@baltimore.ie
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: 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.
Russ Housleyは、Spyrusで雇用されている間にこの仕様の開発を支援したSpyrusの経営陣に感謝します。Russ Housleyはまた、RSA Laboratoriesの経営陣に感謝します。RSALaboratoriesは、仕事の変更後に仕様の完了をサポートしました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。