RFC3281 日本語訳
3281 An Internet Attribute Certificate Profile for Authorization. S.Farrell, R. Housley. April 2002. (Format: TXT=90580 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Farrell
Request for Comments: 3281 Baltimore Technologies
Category: Standards Track R. Housley
RSA Laboratories
April 2002
コメントを求めるワーキンググループS.ファレル要求をネットワークでつないでください: 3281年のボルチモア技術カテゴリ: 標準化過程R.Housley RSA研究所2002年4月
An Internet Attribute Certificate
Profile for Authorization
承認のためのインターネット属性証明書プロフィール
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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 Attribute Certificatesの使用のためのプロフィールを定義します。 属性証明書は相互運用性目標の広いスペクトルと操作上と保証要件の、より広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このドキュメントの目標は限られた専用要件と同様に広い相互運用性を必要とする一般的適用のために一般的な基線を確立することです。 プロフィールはインターネット電子メール、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
1. 序論… 2 1.1委譲と交流チェーン… 4 1.2は証明書分配(「牽引力」に対して「押す」)を結果と考えます。 4 1.3 構造を記録してください… 6 2. 用語… 6 3. 要件… 7 4. 証明書プロフィールを結果と考えてください… 7 4.1 X.509は証明書定義を結果と考えます… 8 標準の分野の4.2プロフィール… 10 4.2 .1バージョン… 10 4.2 .2所有者… 11
Farrell & Housley Standards Track [Page 1] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[1ページ]。
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
4.2.3 発行人… 12 4.2 .4署名… 12 4.2 .5通し番号… 12 4.2 .6有効期間… 13 4.2 .7の属性… 13 4.2 .8の発行人のユニークな識別子… 14 4.2 .9の拡大… 14 4.3の拡大… 14 4.3 .1 アイデンティティを監査してください… 14 4.3 .2 交流の狙い… 15 4.3 .3の権威の主要な識別子… 17 4.3 .4 権威情報アクセサリー… 17 4.3 .5 CRL分配は指します… 17 4.3 .6 利用可能な取消しがありません… 18 4.4 タイプを結果と考えてください… 18 4.4 .1 認証情報を修理してください… 19 4.4 .2 アイデンティティにアクセスしてください… 19 4.4 .3 アイデンティティを請求します… 20 4.4 .4 分類してください… 20 4.4 .5の役割… 20 4.4 .6クリアランス… 21 交流発行人のPKCの4.5プロフィール… 22 5. 証明書合法化を結果と考えてください… 23 6. 取消し… 24 7. 任意の特徴… 25 7.1 暗号化を結果と考えてください… 25 7.2 Proxyingします… 27 7.3 ObjectDigestInfoの使用… 28 7.4 AAは制御します… 29 8. セキュリティ問題… 30 9. IANA問題… 32 10. 参照… 32 付録A: オブジェクト識別子… 34 付録B: ASN.1モジュール… 35作者のアドレス… 39の承認… 39 完全な著作権宣言文… 40
1. Introduction
1. 序論
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119)で説明されるように本書では解釈されることであるべきです。
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
X.509公開鍵証明書(PKCs)[X.509-1997、X.509-2000、PKIXPROF]はアイデンティティと公開鍵を縛ります。 属性証明書(西暦)はPKCと同様の構造です。 西暦が公開鍵を全く含んでいないということである主な違い。 西暦は含むかもしれません。
Farrell & Housley Standards Track [Page 2] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[2ページ]。
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証明書」という用語をあいまいにして、西暦の構文はRecommendation 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.
PKCsとACsを絶えず混乱させる人々もいます。 類推は区別を明らかにするかもしれません。 PKCがパスポートに似ていると考えることができます: それは、所有者を特定して、長い間続く傾向があって、得るために些細であるべきではありません。 西暦はさらに入国査証に似ています: それは、異なった権威によって通常発行されて、同じくらい長い時間、続きません。 入国査証を取得するのが、パスポートを提示するのを通常必要とするとき、ビザを取得するのは、より簡単なプロセスであるかもしれません。
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の拡大に置かれるか、または別々の属性証明書(西暦)に置かれるかもしれません。 通常、PKCsの承認情報のプレースメントは2つの理由で望ましくありません。 まず最初に、承認情報には、アイデンティティと公開鍵の結合と同じ寿命がしばしばあるというわけではありません。 承認情報がPKCの拡大に置かれるとき、一般的な結果はPKCの役に立つ生涯の短縮です。 2番目に、承認情報には、通常、PKC発行人は正式ではありません。 PKC発行人が権威筋から承認情報を得るように、これは追加ステップに結果として生じます。
For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes.
これらの理由で、PKCと承認情報をしばしば切り離すほうがよいです。 しかし、また、承認情報は、アイデンティティに縛られる必要があります。 西暦はこの結合を提供します。 それは単にデジタルに署名していて(公認される)のアイデンティティとセットの属性です。
An AC may be used with various security services, including access control, data origin authentication, and non-repudiation.
西暦はアクセスコントロール、データ発生源認証、および非拒否を含む様々なセキュリティー・サービスと共に使用されるかもしれません。
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.
PKCsは、コントロール決定関数にアクセスするためにアイデンティティを提供できます。 しかしながら、多くの文脈では、アイデンティティはアクセス制御決定、むしろ役割に使用される評価基準ではありませんアクセサのグループ会員資格が使用される評価基準です。 そのようなアクセス制御体系は役割のベースのアクセスコントロールと呼ばれます。
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.
西暦に基づくアクセス制御決定をするとき、アクセス制御決定関数は、適切な交流所有者がアクセサリーを要求した実体であることを保証する必要があるかもしれません。 要求かアイデンティティと西暦の間のリンケージを達成できる1つの方法は、アクセス要求の中の西暦の中のPKCの参照の包含とPKCに対応する秘密鍵の認証の使用です。
Farrell & Housley Standards Track [Page 3] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[3ページ]。
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はデータ発生源認証サービスの、そして、非拒否サービスの文脈で使用されるかもしれません。 これらの文脈に、西暦に含まれた属性は署名実体に関する追加情報を提供します。 実体がデータに署名するのが認可されるのを確実にするのにこの情報を使用できます。 この種類の照合はデータが交換される文脈、または、デジタルに署名されたデータによります。
1.1 Delegation and AC chains
1.1 委譲と交流チェーン
The X.509 standard [X.509-2000] defines authorization as the "conveyance of privilege from one entity that holds such privilege, to another entity". An AC is one authorization mechanism.
X.509規格[X.509-2000]は「そのような特権を保持する1つの実体から別の実体までの特権の運送」と承認を定義します。 西暦は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.
特権asserterの特権の信憑性について確かめるのに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.
そのような交流チェーンに関連している管理と処理が複雑であり、今日のインターネットでのACsの使用がかなり限られているので、この仕様はどんなRECOMMENDにも交流チェーンを使用しません。 他の(将来)の仕様は交流チェーンの使用を扱うかもしれません。 この仕様は簡単なケースに対処します。そこでは、1つの権威が特定のセットの属性のためにACsのすべてを発行します。 しかしながら、この簡素化はいくつかの異なった当局の使用を排除しません。それはそれぞれ異なったセットの属性を管理します。 例えば、グループ会員資格は1つの権威によって発行された西暦1年に含まれるかもしれません、そして、機密取扱者の人物調査は別の権威によって発行された別の西暦に含まれるかもしれません。
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].
これは、一度に単一の西暦を処理できるようにconformant実装がREQUIREDにすぎないことを意味します。 西暦1以上年の処理が相次いで必要であるかもしれません。 しかしながら、西暦のその合法化が[PKIXPROF]で指定されるようにPKCsのチェーンの合法化を必要とするかもしれないことに注意してください。
1.2 Attribute Certificate Distribution ("push" vs. "pull")
1.2 属性証明書分配(「牽引力」に対する「プッシュ」)
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
いくつかの環境で、クライアントがサーバに西暦を「押す」であることは、適当です。これは、クライアントとサーバとのどんな新しい関係も必要でないことを意味します。 また、それは検索負担が全くサーバに課されないで、(性能を向上させます)交流検証がそうであることを意味します。
Farrell & Housley Standards Track [Page 4] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[4ページ]。
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.
それが「知るために必要である」もので提示されているだけです。 「プッシュ」モデルはクライアントの権利がクライアントの「ホーム」ドメインの中で割り当てられるべきである相互ドメイン場合で特に適当です。
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.
他の場合では、クライアントの西暦が交流発行人か倉庫からの要求するか、または「引く」であることが単にサーバに認証するクライアントとサーバにより適しています。 「牽引力」モデルの主要な利益はクライアント、または、クライアント/サーバプロトコルへの変化なしでそれを実装することができるということです。 「牽引力」モデルはクライアントの権利がクライアントのドメインの中でというよりむしろサーバのドメインの中で割り当てられるべきである相互ドメインケースに特に適しています。
There are a number of possible exchanges involving three entities: the client, the server, and the AC issuer. In addition, a directory service or other repository for AC retrieval MAY be supported.
3つの実体にかかわる多くの可能な交換があります: クライアント、サーバ、および交流発行人。 さらに、交流検索のためのディレクトリサービスか他の倉庫が支えられるかもしれません。
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: 交流交換
Farrell & Housley Standards Track [Page 5] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[5ページ]。
1.3 Document Structure
1.3 ドキュメント構造
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は交流合法化のための規則を指定します。 セクション6は交流取消しチェックのための規則を指定します。 セクション7はサポートされるかもしれないオプション機能を指定します。 しかしながら、これらの特徴のサポートは順応にこのプロフィールに必要ではありません。 最終的に、付録はこの仕様とASN.1モジュールをサポートしなければならなかったOIDsのリストを含んでいます。
2. Terminology
2. 用語
For simplicity, we use the terms client and server in this specification. This is not intended to indicate that ACs are only to be used in client-server environments. For example, ACs may be used in the S/MIME v3 context, where the mail user agent would be both a "client" and a "server" in the sense the terms are used here.
簡単さのために、私たちはこの仕様で用語クライアントとサーバを使用します。 これが、ACsがクライアント/サーバ環境で単に使用されることになっているのを示すことを意図しません。 例えば、ACsはS/MIME v3文脈で使用されるかもしれなくて、用語はここでメールユーザエージェントが両方が「クライアント」と意味で「サーバ」であるなら使用するところで使用されます。
Term Meaning
用語意味
AA Attribute Authority, the entity that issues the
AC, synonymous in this specification with "AC
issuer"
AC Attribute Certificate
AC user any entity that parses or processes an AC
AC verifier any entity that checks the validity of an AC and
then makes use of the result
AC issuer the entity which signs the AC, synonymous in this
specification with "AA"
AC holder the entity indicated (perhaps indirectly) in the
holder field of the AC
Client the entity which is requesting the action for
which authorization checks are to be made
Proxying In this specification, Proxying is used to mean
the situation where an application server acts as
an application client on behalf of a user.
Proxying here does not mean granting of authority.
PKC Public Key Certificate - uses the type ASN.1
Certificate defined in X.509 and profiled in RFC
2459. This (non-standard) acronym is used in order
to avoid confusion about the term "X.509
certificate".
Server the entity which requires that the authorization
checks are made
AA Attribute Authority、西暦を発行する実体、同義である、「交流発行人」交流Attribute Certificate交流ユーザに伴うこの仕様の西暦の正当性をチェックするどんな実体とその時も結果交流発行人の使用をする交流交流検証を分析するか、または処理するどんな実体、も西暦に署名する実体; 同義である、"AA"交流所有者とのこの仕様では、実体は交流クライアントの所有者分野でこの仕様で許可検査がことである人工のProxyingである動作を要求している実体を示して(恐らく間接的に)、Proxyingは、アプリケーション・サーバーがアプリケーションクライアントとしてユーザを代表して機能する状況を意味するのに使用されます。 ここでProxyingするのは権威を意地悪な与えないことをします。 PKC Public Key Certificate--タイプASN.1CertificateがX.509で定義して、RFC2459で輪郭を描いた用途。 この(標準的でない)の頭文字語は、「X.509証明書」というおよそ期間、混乱を避けるのに使用されています。 サーバは許可検査をするのを必要とする実体です。
Farrell & Housley Standards Track [Page 6] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[6ページ]。
3. Requirements
3. 要件
This AC profile meets the following requirements.
この交流プロフィールは以下の必要条件を満たします。
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のために、サポートします。 典型的な短命な有効期間はPKCsのための何カ月ものと対照的に何時間も測定されるかもしれません。 短い有効期間は、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. 標準の属性タイプは交流検証が異なったドメインの同じ属性の用途を見分けることを許可する方法で定義されるべきです。 例えば、ボルチモアによって定義される「管理者グループ」とSPYRUSによって定義される「管理者グループ」は容易に区別されるべきです。
Targeting of ACs:
ACsの狙い:
5. It should be possible to "target" an AC at one, or a small number
of, servers. This means that a trustworthy non-target server will
reject the AC for authorization decisions.
5. それが1、または少ない数で西暦を「狙うこと」において可能であるべきである、サーバ。 これは、信頼できる非目標サーバが承認決定のために西暦を拒絶することを意味します。
Push vs. Pull
牽引力に対して押してください。
6. ACs should be defined so that they can either be "pushed" by the
client to the server, or "pulled" by the server from a repository
or other network service, including an online AC issuer.
6. ACsは倉庫か他のネットワーク・サービスから彼らをサーバへのクライアントが「押す」か、またはサーバで「引くことができる」ように定義されるべきです、オンライン交流発行人を含んでいて。
4. Attribute Certificate Profile
4. 属性証明書プロフィール
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
ACsは相互運用性目標の広いスペクトルと操作上と保証要件の、より広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このドキュメントの目標は専用である状態で広い相互運用性を必要として、制限された一般的適用のために一般的な基線を確立することです。
Farrell & Housley Standards Track [Page 7] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[7ページ]。
requirements. In particular, the emphasis will be on supporting the use of attribute certificates for informal Internet electronic mail, IPSec, and WWW applications.
要件。 特に、強調が属性証明書の非公式のインターネット電子メール、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(後で)バージョンを使用しますが、このドキュメントは1988年のASN.1構文を使用します、PKCs[PKIXPROF]のためにしたように。 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.
実装を従わせると、このセクションで指定されたプロフィールは支えられなければなりません。
4.1 X.509 Attribute Certificate Definition
4.1 X.509属性証明書定義
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は以下に与えられた西暦の定義を含んでいます。 [PKIXPROF]で本書では定義されないすべてのタイプは見つけることができます。
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificate:、:= 系列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
}
AttributeCertificateInfo:、:= 系列バージョンAttCertVersion、--バージョンはv2です、所有者Holder、発行人AttCertIssuer、署名AlgorithmIdentifier、serialNumber CertificateSerialNumber、attrCertValidityPeriod AttCertValidityPeriod、属性SEQUENCE OF Attribute、issuerUniqueID UniqueIdentifier OPTIONAL、拡大Extensions OPTIONAL
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
AttCertVersion:、:= INTEGER v2(1)、所有者:、:= SEQUENCE、baseCertificateID[0]IssuerSerial OPTIONAL--、発行人と通し番号、--、所有者のPublic Key Certificate
Farrell & Housley Standards Track [Page 8] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[8ページ]。
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
}
entityName[1]GeneralNames OPTIONAL--役割のobjectDigestInfo[2]ObjectDigestInfo OPTIONAL--主張者か直接所有者を認証するのに使用される名前--例えば、実行可能
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
ObjectDigestInfo:、:= 系列digestedObjectType ENUMERATED、publicKey(0)、publicKeyCert(1)、otherObjectTypes(2)--otherObjectTypesはそうしてはいけません--このプロフィール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
}
AttCertIssuer:、:= 選択{v1Form GeneralNames(これで使用されてはいけない)はv2Form[0]V2Formの輪郭を描きます--v2専用}
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
}
V2Form:、:= 系列issuerName GeneralNames OPTIONAL、baseCertificateID[0]IssuerSerial OPTIONAL、objectDigestInfo[1]ObjectDigestInfo OPTIONAL--issuerNameはこのプロフィールに存在していなければなりません--baseCertificateIDとobjectDigestInfoはそうしてはいけません--、このプロフィールに存在してください。
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
IssuerSerial:、:= 系列発行人GeneralNames、連続のCertificateSerialNumber、issuerUID UniqueIdentifier OPTIONAL
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
AttCertValidityPeriod:、:= 系列notBeforeTime GeneralizedTime、notAfterTime GeneralizedTime
Farrell & Housley Standards Track [Page 9] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[9ページ]。
Although the Attribute syntax is defined in [PKIXPROF], we repeat the definition here for convenience.
Attribute構文は[PKIXPROF]で定義されますが、私たちは便宜のためにここで定義を繰り返します。
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
以下を結果と考えてください:= 系列AttributeType、値のSET OF AttributeValueをタイプしてください--少なくとも1つの値が必要です。
AttributeType ::= OBJECT IDENTIFIER
AttributeType:、:= オブジェクト識別子
AttributeValue ::= ANY DEFINED BY AttributeType
AttributeValue:、:= 何でも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.
Implementersは、SET OF値のDERコード化([X.509 1988]を見てください、[X.208-1988])が、値のencodingsを注文するのを必要とすることに注意するはずです。 この問題は、分類名に関して起こって、[PKIXPROF]実装によって扱われなければなりませんが、それはこのような関係においてははるかに重要です、複数の値の包含がACsではるかに一般的であるので。
4.2 Profile of Standard Fields
4.2 標準の分野のプロフィール
GeneralName offers great flexibility. To achieve interoperability, in spite of this flexibility, this profile imposes constraints on the use of GeneralName.
GeneralNameはかなりの柔軟性を提供します。 この柔軟性にもかかわらず、相互運用性を達成するために、このプロフィールはGeneralNameの使用に規制を課します。
Conforming implementations MUST be able to support the dNSName, directoryName, uniformResourceIdentifier, and iPAddress options. This is compatible with the GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7).
実装を従わせると、dNSName、directoryName、uniformResourceIdentifier、およびiPAddressにオプションをサポートできなければなりません。 中で4.2を主に区分してください。これは[PKIXPROF]のGeneralName要件と互換性がある、(.1 .7)。
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options.
実装を従わせると、x400Address、ediPartyName、またはregisteredIDオプションが使用されてはいけません。
Conforming implementations MAY use the otherName option to convey name forms defined in Internet Standards. For example, Kerberos [KRB] format names can be encoded into the otherName, using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and the PrincipalName.
実装を従わせると、otherNameオプションは、インターネットStandardsで定義された名前書式を伝えるのに使用されるかもしれません。 例えば、ケルベロス[KRB]形式名をotherNameにコード化できます、ケルベロス5の主要な名前OIDとRealmとPrincipalNameのSEQUENCEを使用して。
4.2.1 Version
4.2.1 バージョン
The version field MUST have the value of v2. That is, the version field is present in the DER encoding.
バージョン分野には、v2の値がなければなりません。 すなわち、バージョン分野はDERコード化で存在しています。
Farrell & Housley Standards Track [Page 10] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[10ページ]。
Note: This version (v2) is not backwards compatible with the previous attribute certificate definition (v1) from the 1997 X.509 standard [X.509-1997], but is compatible with the v2 definition from X.509 (2000) [X.509-2000].
以下に注意してください。 このバージョン(v2)は、後方に1997年のX.509規格[X.509-1997]からの前の属性証明書定義(v1)と互換性があった状態でありませんが、X.509(2000)[X.509-2000]からのv2定義と互換性があります。
4.2.2 Holder
4.2.2 所有者
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.
Holder分野は3つの異なった(任意の)構文を許容するSEQUENCEです: baseCertificateID、entityName、およびobjectDigestInfo。 1つのオプションだけが存在しているところでは、Holder分野の意味は明確です。 しかしながら、オプションが「規範的である」混乱の可能性が1つ以上のオプションが使用されているところにあります。(それは、「ヒント」などです)。 以来、オプションの1つだけがどんな与えられた西暦でも使用されるという正しい位置は[X.509-2000]、この仕様RECOMMENDSから明確ではありません。
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.
西暦が認証されたメッセージかセッションのときに通過されて、認証がX.509 PKCの使用に基づいているどんな環境のためにも、所有者分野SHOULDは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と発行人は交流所有者分野と同じであるに違いありません。 PKC発行人には、directoryName分野のholder.baseCertificateID.issuer構造物のただ一つの値として存在していることである非空の分類名がなければなりません。 所有者のPKCがissuerUniqueID分野を含むなら、交流holder.baseCertificateID.issuerUID分野を使用するだけでよいです。 交流holder.baseCertificateID.issuerUIDとPKC issuerUniqueID分野の両方が存在しているなら、同じ値は両方の分野に存在していなければなりません。 したがって、baseCertificateIDはPKC発行人分野が非空の分類名値を含むのを強制するPKCプロフィール(好きです[PKIXPROF])で使用可能であるだけです。
Note: An empty distinguished name is a distinguished name where the SEQUENCE OF relative distinguished names is of zero length. In a DER encoding, this has the value '3000'H.
以下に注意してください。 空の分類名はSEQUENCE OFの相対的な分類名がゼロ・レングスのものであることの分類名です。 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 subjectAltName分野拡張子の値の1つと同じ、そして、(現在。)でなければなりません。 [PKIXPROF]が、subjectAltName拡張子がPKC対象が空の分類名であるなら存在しているのを強制することに注意してください。 entityNameオプションを使用するとき起こるかもしれないいくつかの名前衝突問題について言及するセキュリティ問題部を見てください。
In any other case where the holder field uses the entityName option, only one name SHOULD be present.
1つの名前だけのSHOULD、所有者分野がentityNameオプションを使用するいかなる他の場合ではも、存在してください。
Farrell & Housley Standards Track [Page 11] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[11ページ]。
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.
SHOULDが指定するこのプロフィールに従う使用されているそれの交流所有者オプションがことであるどんなプロトコルともこれはどうそのプロトコルで定義されるサポートしている認証体系と合うか。
4.2.3 Issuer
4.2.3 発行人
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選択を使用しなければなりません。(それは、issuerNameに唯一無二の1GeneralNameを含まなければなりません)。(issuerNameはdirectoryName分野に非空の分類名を保管しなければなりません)。 これは、すべての交流発行人には非空の分類名がなければならないことを意味します。 このプロフィールに従う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の使用の理由の一部は交流発行人が、交流検証がそれ(交流発行人)にどのPKCを使用するかを知る必要はないことを意味するということです。 baseCertificateID分野を参照に使用して、交流発行人は、交流検証が交流発行人が交流作成時間に選んだ(それ自体のために)PKCを信じなければならないことを意味するでしょう。
4.2.4 Signature
4.2.4 署名
Contains the algorithm identifier used to validate the AC signature.
交流署名を有効にするのに使用されるアルゴリズム識別子を含んでいます。
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つであるに違いありません。 従う実装は指定しなければなりません。/SHOULD/5月がアルゴリズム声明に調印して、すべてがそうしなければならない名誉は[PKIXALGS]で指定しました。
4.2.5 Serial Number
4.2.5 通し番号
For any conforming AC, the issuer/serialNumber pair MUST form a unique combination, even if ACs are very short-lived.
どんな従う西暦に関してはも、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.
すなわち、INTEGER価値のDERコード化における符号ビットはゼロであるに違いありません--交流発行人は、serialNumberが正の整数であることを強制しなければならなくて、これは、必要なら、主である(一番左)'H'00八重奏を加えることによって、終わることができます。 これは一連の八重奏と整数値の間にマッピングの潜在的あいまいさを移します。
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.
上記のユニークさとタイミング要件を考えて、通し番号が長整数型を含むと予想できます。 交流ユーザは4つの八重奏より長い間、serialNumber値を扱うことができなければなりません。 Conformant ACsは20の八重奏より長い間、serialNumber値を含んではいけません。
Farrell & Housley Standards Track [Page 12] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[12ページ]。
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.
どんな交流発行人によっても使用された通し番号がどんな特定の注文にも続くという要件が全くありません。 特に、彼らは、時間に従って単調に増加する必要がありません。 それぞれの交流発行人は、それが発行する各西暦がユニークな通し番号を含むのを確実にしなければなりません。
4.2.6 Validity Period
4.2.6 有効期間
The attrCertValidityPeriod (a.k.a. validity) field specifies the period for which the AC issuer certifies that the binding between the holder and the attributes fields will be valid.
attrCertValidityPeriod(通称正当性)分野は交流発行人が有効であることを所有者と属性分野の間の結合がなる公認する期間を指定します。
The generalized time type, GeneralizedTime, is a standard ASN.1 type for variable precision representation of time. The GeneralizedTime field can optionally include a representation of the time differential between the local time zone and Greenwich Mean Time.
一般化された時間タイプ(GeneralizedTime)は時間の可変精度表現のための標準のASN.1タイプです。 GeneralizedTime分野は現地時間のゾーンとグリニッジ標準時の間に任意に時間デフ装置の表現を含むことができます。
For the purposes of this profile, GeneralizedTime values MUST be expressed in Coordinated universal time (UTC) (also known as Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
このプロフィールの目的のために、GeneralizedTime値は、Coordinatedユニバーサルタイム(UTC)(また、グリニッジ標準時かズールー族として、知られている)の間、表さなければならなくて、秒を含まなければなりません(すなわち、回はYYYYMMDDHHMMSSZです)、秒数がゼロでさえあるときに。 GeneralizedTime値は断片的な秒を含んではいけません。
(Note: this is the same as specified in [PKIXPROF], section 4.1.2.5.2.)
(注意: これは[PKIXPROF]、セクション4.1.2で.2に.5を指定するのと同じです)
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.
交流ユーザは過去か将来処理時点で有効期間かそのすべての有効期間の部品を持つ西暦(先日付を書かれた西暦)を扱うことができなければなりません。 バックアップなどのいくつかのアプリケーションに、これは有効です。
4.2.7 Attributes
4.2.7 属性
The attributes field gives information about the AC holder. When the AC is used for authorization, this will often contain a set of privileges.
属性野原は交流所有者に関して知らせます。 西暦が承認に使用されるとき、これはしばしば1セットの特権を含むでしょう。
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.
属性分野はSEQUENCE OF Attributeを含んでいます。 各AttributeはSET OF値を含むかもしれません。 与えられた西暦に関しては、系列のそれぞれのAttributeType OBJECT IDENTIFIERはユニークであるに違いありません。 すなわち、それぞれの属性の1つのインスタンスしか単一の西暦に起こることができませんが、それぞれのインスタンスはマルチ評価できます。
AC users MUST be able to handle multiple values for all attribute types.
交流ユーザはすべての属性タイプのために複数の値を扱うことができなければなりません。
An AC MUST contain at least one attribute. That is, the SEQUENCE OF Attributes MUST NOT be of zero length.
西暦は少なくとも1つの属性を含まなければなりません。 すなわち、SEQUENCE OF Attributesはゼロ・レングスのものであるはずがありません。
Farrell & Housley Standards Track [Page 13] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[13ページ]。
Some standard attribute types are defined in section 4.4.
セクション4.4で定義される標準の属性タイプもいます。
4.2.8 Issuer Unique Identifier
4.2.8 発行人のユニークな識別子
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.
また、それが交流発行人のPKCに使用されない場合、この分野を使用してはいけません、その場合、それを使用しなければなりません。 [PKIXPROF]が、この分野SHOULD NOTがCAsを従わせることによって使用されますが、アプリケーションSHOULDが分野を含むPKCsを分析できると述べることに注意してください。
4.2.9 Extensions
4.2.9 拡大
The extensions field generally gives information about the AC as opposed to information about the AC holder.
一般に、拡大野原は交流所有者の情報と対照的に西暦に関して知らせます。
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.
拡張子を全く持っていない西暦はプロフィールに従います。 しかしながら、セクション4.3はこのプロフィールとそれらが重要であるとマークされるかもしれないかどうかと共に使用されるかもしれない拡張子を定義します。 いかなる他の重要な拡大も使用されているなら、西暦はこのプロフィールに従いません。 しかしながら、いかなる他の非臨界拡大も使用されているなら、西暦はこのプロフィールに従います。
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のために定義された拡大は追加属性を関連づけるためのメソッドに所有者を提供します。 また、このプロフィールで、共同体は、それらの共同体にユニークな情報を運ぶために個人的な拡大を定義できます。 西暦での各拡大は重要であるか非臨界であるとして指定されるかもしれません。 認識しない重要な拡大に遭遇するなら、交流使用システムは西暦を拒絶しなければなりません。 しかしながら、それが認識されないなら、非臨界拡大は無視されるかもしれません。 セクション4.3は情報にインターネットACsと標準の位置の中で使用されたお勧めの拡張子を提示します。 共同体は、追加拡張子を使用するのを選ぶかもしれません。 しかしながら、警告は一般情勢における使用を防ぐかもしれないACsでのどんな重要な拡大も採用するのに訓練されるべきです。
4.3 Extensions
4.3 拡大
4.3.1 Audit Identity
4.3.1 監査のアイデンティティ
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.
いくつかの事情では、監査証跡が直接個人を特定する記録を含まないのが必要です(例えば、データ保護/データプライバシー法律で)。 この状況で、交流所有者分野の使用は監査証跡で使用に不適当になるかもしれません。
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.
そのような場合を考慮するために、西暦は監査アイデンティティ拡大を含むかもしれません。 理想的にそれ、SHOULD、監査アイデンティティ価値から交流発行人の協力なしで交流所有者のアイデンティティを得るのにおいて、実行不可能であってください。
Farrell & Housley Standards Track [Page 14] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[14ページ]。
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.
値、そして交流発行人/シリーズに伴う監査のアイデンティティSHOULDでは、監査/伐採目的には、使用されてください。 監査のアイデンティティの値が適当に選ばれているなら、サーバ/サービス管理者は、交流所有者を特定できないで交流所有者の動きを追跡するのに監査証跡を使用できます。
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.
交流発行人と組み合わせたサーバ/サービス管理者は不正行為が検出される場合で交流所有者を特定できなければなりません。 これは、交流発行人が監査のアイデンティティから交流所有者の実際のアイデンティティを決定できなければならないことを意味します。
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.
もちろん、監査は交流発行人/シリーズ組に基づくことができました。 しかしながら、このメソッドは、複数のACsがある同じ交流所有者に追跡するのを許容しません。 したがって、典型的な交流生涯より長い間続く場合にだけ、監査のアイデンティティは役に立ちます。 また、監査は交流所有者のPKC発行人/シリーズに基づくことができました。 しかしながら、これで、サーバ/サービス管理者はしばしば交流所有者を特定できるでしょう。
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.
そうでなければ、交流検証が監査目的に交流所有者かある他の特定値を使用するかもしれないので、使用されると、この拡大は重要であるに違いありません。
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を使用するプロトコルがワイヤの上にしばしばビットの交流所有者のアイデンティティを暴露するでしょう。 そのような場合、不透明な監査のアイデンティティで、西暦の使用は匿名になりません。 それは、続く監査証跡が身元が分かる情報を含まないのを単に確実にします。
The value of an audit identity MUST be longer than zero octets. The value of an audit identity MUST NOT be longer than 20 octets.
監査のアイデンティティの値はどんな八重奏よりも長いはずがありません。 監査のアイデンティティの値は20の八重奏より長いはずがありません。
name id-pe-ac-auditIdentity
OID { id-pe 4 }
syntax OCTET STRING
criticality MUST be TRUE
名前イド-pe-ac-auditIdentity OIDイド-pe4構文OCTET STRINGの臨界はTRUEであるに違いありません。
4.3.2 AC Targeting
4.3.2 交流の狙い
To target an AC, the target information extension, imported from [X.509-2000], MAY be used to specify a number of servers/services. The intent is that the AC SHOULD only be usable at the specified servers/services. An (honest) AC verifier who is not amongst the named servers/services MUST reject the AC.
西暦を狙うなら、[X.509-2000]からインポートされた目標情報拡張子は、多くのサーバ/サービスを指定するのに使用されるかもしれません。 意図はAC SHOULDが単に指定されたサーバ/サービスのときに使用可能であるということです。 (正直)のそうする交流検証は命名されたサーバ/サービスの中で西暦を拒絶してはいけません。
If this extension is not present, the AC is not targeted and may be accepted by any server.
この拡大が存在していないなら、西暦は狙わないで、どんなサーバでも受け入れるかもしれません。
Farrell & Housley Standards Track [Page 15] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[15ページ]。
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
}
以下を狙ってください:= 選択targetName[0]GeneralName、targetGroup[1]GeneralName、targetCert[2]TargetCert
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
TargetCert:、:= 系列targetName GeneralName任意の、そして、certDigestInfo ObjectDigestInfo任意のtargetCertificate IssuerSerial
The targetCert CHOICE within the Target structure is only present to allow future compatibility with [X.509-2000] and MUST NOT be used.
Target構造の中のtargetCert CHOICEは単に[X.509-2000]との将来の互換性を許容するために存在していて、使用されてはいけません。
The targets check passes if the current server (recipient) is one of the targetName fields in the Targets SEQUENCE, or if the current server is a member of one of the targetGroup fields in the Targets SEQUENCE. In this case, the current server is said to "match" the targeting extension.
目標は現在のサーバ(受取人)がTargets SEQUENCEのtargetName分野の1つである、または現在のサーバがTargets SEQUENCEのtargetGroup分野の1つのメンバーであるならパスをチェックします。 この場合、現在のサーバは狙い拡大に「合わせている」と言われます。
How the membership of a target within a targetGroup is determined is not defined here. It is assumed that any given target "knows" the names of the targetGroups to which it belongs or can otherwise determine its membership. For example, the targetGroup specifies a DNS domain, and the AC verifier knows the DNS domain to which it belongs. For another example, the targetGroup specifies "PRINTERS," and the AC verifier knows whether or not it is a printer or print server.
targetGroupの中の目標の会員資格がどう決定しているかはここで定義されません。 どんな与えられた目標もそれが属するtargetGroupsという名前を「知っている」か、または別の方法で会員資格を決定できると思われます。 例えば、targetGroupはDNSドメインを指定します、そして、交流検証はそれが属するDNSドメインを知っています。 別の例として、targetGroupは「プリンタ」を指定して、交流検証は、それがプリンタかそれともプリント・サーバであるかどうかを知っています。
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]は「目標の系列」と拡大構文を定義します。 実装が生産するだけでよい交流発行人を従わせて、1つは要素を「狙います」。 交流ユーザを確認すると、「目標の系列」を受け入れることができなければなりません。 1つ以上のTargets要素が西暦で見つけられるなら、まるですべてのTarget要素が1つのTargets要素の中で見つけられたかのように拡大を扱わなければなりません。
name id-ce-targetInformation
OID { id-ce 55 }
syntax SEQUENCE OF Targets
criticality MUST be TRUE
名前、イドCe targetInformation OID、SEQUENCE OF Targetsの臨界がそうしなければならないイドCe55構文、TRUEになってください。
Farrell & Housley Standards Track [Page 16] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[16ページ]。
4.3.3 Authority Key Identifier
4.3.3 権威の主要な識別子
The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY be used to assist the AC verifier in checking the signature of the AC. The [PKIXPROF] description should be read as if "CA" meant "AC issuer." As with PKCs, this extension SHOULD be included in ACs.
[PKIXPROF]で輪郭を描かれるauthorityKeyIdentifier拡張子は、西暦の署名をチェックするのに交流検証を助けるのに使用されるかもしれません。 まるで「カリフォルニア」が「交流発行人」を意味するかのように[PKIXPROF]記述は読まれるべきです。 PKCs、この拡大SHOULD、ACsで含められてください。
Note: An AC, where the issuer field used the baseCertificateID CHOICE, would not need an authorityKeyIdentifier extension, as it is explicitly linked to the key in the referred certificate. However, as this profile states (in section 4.2.3), ACs MUST use the v2Form with issuerName CHOICE, this duplication does not arise.
以下に注意してください。 西暦は発行人分野がbaseCertificateID CHOICEを使用したところでauthorityKeyIdentifier拡張子を必要としないでしょう、それが参照された証明書で明らかにキーにリンクされるとき。 しかしながら、このプロフィールが述べるように(セクション4.2.3で)、ACsはissuerName CHOICEとv2Formを使用しなければならなくて、この複製は起こりません。
name id-ce-authorityKeyIdentifier
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE
名前、イドCe authorityKeyIdentifier OID、AuthorityKeyIdentifierの臨界がそうしなければならないイドCe35構文、FALSEになってください。
4.3.4 Authority Information Access
4.3.4 権威情報アクセス
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]で定義されるauthorityInformationAccess拡張子は、西暦の取消し状態をチェックするのに交流検証を助けるのに使用されるかもしれません。 サポート、イド広告caIssuers accessMethod、交流チェーンが期待していないので、NOT REQUIREDがこのプロフィールでありますか?
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プロトコルを使用して:
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1
The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location.
accessLocationはURIを含まなければなりません、そして、URIはOCSP応答者の位置を指定するHTTP URL[URL]を含まなければなりません。 交流発行人はもちろんこの位置でOCSP応答者を維持しなければなりません。
name id-ce-authorityInfoAccess
OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax
criticality MUST be FALSE
名前、イドCe authorityInfoAccess OID、AuthorityInfoAccessSyntaxの臨界がそうしなければならないイド-pe1構文、FALSEになってください。
4.3.5 CRL Distribution Points
4.3.5 CRL分配ポイント
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拡張子は、西暦の取消し状態をチェックするのに交流検証を助けるのに使用されるかもしれません。 取消しに関する詳細に関してセクション6を見てください。
Farrell & Housley Standards Track [Page 17] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[17ページ]。
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拡張子はDistributionPointNameオプションを使用しなければなりません。(それは、fullNameを含まなければなりません)。(fullNameはただ一つの名前フォームを含まなければなりません)。 その名前は分類名かURIのどちらかを含まなければなりません。 URIは、HTTP URLかLDAP URL[URL]のどちらかであるに違いありません。
name id-ce-cRLDistributionPoints
OID { id-ce 31 }
syntax CRLDistPointsSyntax
criticality MUST be FALSE
名前、イドCe cRLDistributionPoints OID、CRLDistPointsSyntaxの臨界がそうしなければならないイドCe31構文、FALSEになってください。
4.3.6 No Revocation Available
4.3.6 利用可能な取消しがありません。
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拡張子で、交流発行人は、取消し情報を全くこの西暦に利用可能にしないのを示すことができます。
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.
この拡大は非臨界であるに違いありません。 この拡大を理解していない交流検証は交流発行人から取消しリストを見つけることができるかもしれませんが、取消しリストは西暦のエントリーを決して含まないでしょう。
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e. '0500'H is the DER encoding)
criticality MUST be FALSE
名前、イドCe noRevAvail OID、NULL(すなわち、'0500'HはDERコード化である)の臨界がそうしなければならないイドCe56構文、FALSEになってください。
4.4 Attribute Types
4.4 属性タイプ
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. それは交流発行人と属性方針権威の間の分離を許容します。 これはただ一つの方針権威(例えば、組織)が属性値を割り当てますが、複数の交流発行人が性能か他の理由で配布される状況の役に立ちます。
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に制限されます。(UTF8Stringは合っているより一般的な構文に関連している複雑さをかなり減少させます)。 この構文を使用するすべてのマルチ評価された属性が制限されるので、各値は値の構文の同じ選択を使用しなければなりません。 例えば、交流発行人はoidがある1つの値とストリングがある2番目の値を使用してはいけません。
Farrell & Housley Standards Track [Page 18] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[18ページ]。
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
IetfAttrSyntax:、:= 系列policyAuthority[0]GeneralNames OPTIONAL、値のSEQUENCE OF CHOICE、八重奏OCTET STRING(oid OBJECT IDENTIFIER)は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つのAttribute値専用」です。 「IetfAttrSyntaxの中の複数の値。」 これはSET OF AttributeValuesを示します。 AttributeTypeはセクション4.2.7で指定されるようにまだ一度起こっているだけです。
4.4.1 Service Authentication Information
4.4.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属性は名前のサーバ/サービスに交流所有者を特定します、そして、属性は任意のサービス特定の認証情報を含むかもしれません。 通常、これは「レガシー」アプリケーションのためのユーザ名/パスワード組を含むでしょう。
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.
この属性は交流検証で提示して、解釈されて、目標システムの中の別々のアプリケーションで認証できる情報を提供します。 これがaccessIdentityのために意図するそれへの異なった使用であるというメモは4.4で.2未満を結果と考えます。
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
イド-aca-authenticationInfo OIDイド-aca1構文SvceAuthInfo値を命名してください: 許容された倍数
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
SvceAuthInfo:、:= 系列サービスGeneralName、ident GeneralName、authInfo OCTET STRING OPTIONAL
4.4.2 Access Identity
4.4.2 アクセスのアイデンティティ
The accessIdentity attribute identifies the AC holder to the server/service. For this attribute the authInfo field MUST NOT be present.
accessIdentity属性はサーバ/サービスに交流所有者を特定します。 この属性のために、authInfo分野は存在しているはずがありません。
Farrell & Housley Standards Track [Page 19] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[19ページ]。
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.
交流所有者の情報を提供するのにこの属性が使用されることを意図して、交流検証(または、交流検証がコンポーネントであるより大きいシステム)によってそれは使用されて、交流検証のシステムの中で交流所有者の動きを認可できます。 これがsvceAuthInfo属性のために意図するそれへの異なった使用であるというメモは4.4で上の.1について説明しました。
name id-aca-accessIdentity
OID { id-aca 2 }
syntax SvceAuthInfo
values: Multiple allowed
イド-aca-accessIdentity OIDイド-aca2構文SvceAuthInfo値を命名してください: 許容された倍数
4.4.3 Charging Identity
4.4.3 充電のアイデンティティ
The chargingIdentity attribute identifies the AC holder for charging purposes. In general, the charging identity will be different from other identities of the holder. For example, the holder's company may be charged for service.
chargingIdentity属性は充電目的のために交流所有者を特定します。 一般に、充電のアイデンティティは所有者の他のアイデンティティと異なるでしょう。 例えば、所有者の会社はサービスのために請求されるかもしれません。
name id-aca-chargingIdentity
OID { id-aca 3 }
syntax IetfAttrSyntax
values: One Attribute value only; multiple values within the
IetfAttrSyntax
イド-aca-chargingIdentity OIDイド-aca3構文IetfAttrSyntax値を命名してください: 1つのAttribute値専用。 IetfAttrSyntaxの中の複数の値
4.4.4 Group
4.4.4 グループ
The group attribute carries information about group memberships of the AC holder.
グループ属性は交流所有者のグループ会員資格の情報を運びます。
name id-aca-group
OID { id-aca 4 }
syntax IetfAttrSyntax
values: One Attribute value only; multiple values within the
IetfAttrSyntax
イドacaグループOIDイド-aca4構文をIetfAttrSyntax値と命名してください: 1つのAttribute値専用。 IetfAttrSyntaxの中の複数の値
4.4.5 Role
4.4.5 役割
The role attribute, specified in [X.509-2000], carries information about role allocations of the AC holder.
[X.509-2000]で指定された役割の属性は交流所有者の役割の配分の情報を運びます。
The syntax used for this attribute is:
この属性に使用される構文は以下の通りです。
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
RoleSyntax:、:= 系列任意のroleAuthority[0]GeneralNames roleName[1]GeneralName
Farrell & Housley Standards Track [Page 20] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[20ページ]。
The roleAuthority field MAY be used to specify the issuing authority for the role specification certificate. There is no requirement that a role specification certificate necessarily exists for the roleAuthority. This differs from [X.500-2000], where the roleAuthority field is assumed to name the issuer of a role specification certificate. For example, to distinguish the administrator role as defined by "Baltimore" from that defined by "SPYRUS", one could put the value "urn:administrator" in the roleName field and the value "Baltimore" or "SPYRUS" in the roleAuthority field.
roleAuthority分野は、役割の仕様証明書に発行機関を指定するのに使用されるかもしれません。 役割の仕様証明書がroleAuthorityのために必ず存在しているという要件が全くありません。 これは[X.500-2000]と異なっています。そこでは、roleAuthority分野が役割の仕様証明書の発行人を命名すると思われます。 例えば、「ボルチモア」によって「SPYRUS」によって定義されたそれから定義されるように管理者の役割を区別するために、人は値値のroleName分野の「つぼ: 管理者」と「ボルチモア」か「SPYRUS」をroleAuthority分野に置くことができました。
The roleName field MUST be present, and roleName MUST use the uniformResourceIdentifier CHOICE of the GeneralName.
roleName分野は存在していなければなりません、そして、roleNameはGeneralNameのuniformResourceIdentifier CHOICEを使用しなければなりません。
name id-at-role
OID { id-at 72 }
syntax RoleSyntax
values: Multiple allowed
役割におけるイドOIDを命名してください、イド、-、72、構文RoleSyntax値: 許容された倍数
4.4.6 Clearance
4.4.6 クリアランス
The clearance attribute, specified in [X.501-1993], carries clearance (associated with security labeling) information about the AC holder.
[X.501-1993]で指定されたクリアランス属性は交流所有者のクリアランス(セキュリティラベリングに関連している)情報を運びます。
The policyId field is used to identify the security policy to which the clearance relates. The policyId indicates the semantics of the classList and securityCategories fields.
policyId分野は、クリアランスが関係する安全保障政策を特定するのに使用されます。 policyIdはclassListとsecurityCategories分野の意味論を示します。
This specification includes the classList field exactly as it is specified in [X.501-1993]. Additional security classification values, and their position in the classification hierarchy, may be defined by a security policy as a local matter or by bilateral agreement. The basic security classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, and top-secret.
ちょうどそれが[X.501-1993]で指定されるようにこの仕様はclassList分野を含んでいます。 追加担保分類値、および分類階層構造の彼らの立場は地域にかかわる事柄としての安全保障政策か二国間条約によって定義されるかもしれません。 基本的なセキュリティ分類階層構造が昇順であります: 無印の、そして、非分類されて、制限されて、秘密の秘密、および最高機密。
An organization can develop its own security policy that defines security classification values and their meanings. However, the BIT STRING positions 0 through 5 are reserved for the basic security classification hierarchy.
組織はセキュリティ分類値とそれらの意味を定義するそれ自身の安全保障政策を開発できます。 しかしながら、BIT STRING位置0〜5は基本的なセキュリティ分類階層構造のために予約されます。
If present, the SecurityCategory field provides further authorization information. The security policy identified by the policyId field indicates the syntaxes that are allowed to be present in the securityCategories SET. An OBJECT IDENTIFIER identifies each of the allowed syntaxes. When one of these syntaxes is present in the securityCategories SET, the OBJECT IDENTIFIER associated with that syntax is carried in the SecurityCategory.type field.
存在しているなら、SecurityCategory分野はさらなる承認情報を提供します。 policyId分野によって特定された安全保障政策はsecurityCategories SETで存在しているのが許容されている構文を示します。 OBJECT IDENTIFIERはそれぞれの許容構文を特定します。 これらの構文の1つがsecurityCategories SETに存在しているとき、その構文に関連しているOBJECT IDENTIFIERはSecurityCategory.type分野で運ばれます。
Farrell & Housley Standards Track [Page 21] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[21ページ]。
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories
[2] SET OF SecurityCategory OPTIONAL
}
クリアランス:、:= 系列policyId[0]オブジェクト識別子、ClassListデフォルトが非分類したclassList[1]、[2]が設定したSecurityCategory任意のsecurityCategories
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2)
confidential (3),
secret (4),
topSecret (5)
}
ClassList:、:= ビット列無印の(0)、(1)、部外秘な(2)秘密の(3)、秘密(4)、topSecret(5)を非分類しました。
SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
SecurityCategory:、:= 系列[0] IMPLICIT OBJECT IDENTIFIERをタイプしてください、そして、値[1]ANY DEFINED BYはタイプします。
-- 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
-- これは以下の通りMACRO構造物を使用して、定義されたオリジナルの構文と同じです: -- SecurityCategory:、:= SEQUENCE--タイプ[0]IMPLICIT SECURITY-CATEGORY([1] ANY DEFINED BYタイプを評価する)----SECURITY-CATEGORY MACRO、:、:= -- 始まってください--記法をタイプしてください:、:= タイプ| 空になってください--、VALUE NOTATION:、:= 値(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
名前クリアランスのイドOID共同iso-ccitt(2) ds(5)モジュール(1)選択された属性タイプ(5)クリアランス(55)構文Clearance--Multipleが許容した[X.501-1993]値から、インポートされます。
4.5 Profile of AC issuer's PKC
4.5 交流発行人のPKCのプロフィール
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,
交流発行人のPKCは[PKIXPROF]に従わなければなりません、そして、PKCにおけるkeyUsage拡張子はデジタル署名を有効にするのに交流発行人の公開鍵を使用できないのを明らかに示してはいけません。 通し番号と取消しに関して混乱を避けてください。
Farrell & Housley Standards Track [Page 22] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[22ページ]。
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.
また、交流発行人はPKC Issuerであるはずがありません。 すなわち、交流発行人はまた、カリフォルニアであるはずがありません。 それで、交流発行人のPKCはcAのブールセットによるbasicConstraints拡張子をTRUEに持ってはいけません。
5. Attribute Certificate Validation
5. 属性証明書合法化
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が満足させなければならないという基本的なセットの規則について説明します。 また、実装する検証がそれの西暦を選ぶかもしれないいくつかの追加チェックが説明されます。
To be valid an AC MUST satisfy all of the following:
有効に、なるように、西暦は以下のすべてを満たさなければなりません:
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を認証するPKCを使用するか見つけなければなりません、そして、[PKIXPROF]に従って、そのPKCの全体の証明経路について確かめなければなりません。 セキュリティ問題部で注意されるように、ある他の認証体系が使用されているなら、交流検証は、アイデンティティ(アイデンティティ、所有者分野を認証する)がかかわった非常に慎重なマッピングである必要があります。
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. 交流署名が暗号でそうであるに違いない、正しい、そして、交流発行人の全体のPKC[PKIXPROF]。証明経路について確かめなければならない
3. The AC issuer's PKC MUST also conform to the profile specified in
section 4.5 above.
3. また、交流発行人のPKCは上のセクション4.5で指定されたプロフィールに従わなければなりません。
4. The AC issuer MUST be directly trusted as an AC issuer (by
configuration or otherwise).
4. 交流発行人(構成かそうでないのによる)として直接交流発行人を信じなければなりません。
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. 交流の正当性の中に西暦が評価されている時間があるに違いありません。 評価時間がnotBeforeTimeかnotAfterTimeのどちらかと等しいなら、西暦はタイムリーです、そして、このチェックは成功します。 使用目的によっては、評価時間が現在の時間と同じでないかもしれないことに注意してください。
6. The AC targeting check MUST pass as specified in section 4.3.2.
6. チェックを狙う西暦はセクション4.3.2で指定されるように通らなければなりません。
7. If the AC contains an unsupported critical extension, the AC MUST
be rejected.
7. 西暦がサポートされない重要な拡大を含んでいるなら、西暦を拒絶しなければなりません。
Support for an extension in this context means:
拡大には、このような関係においては手段をサポートしてください:
1. The AC verifier MUST be able to parse the extension value.
1. 交流検証は拡大値を分析できなければなりません。
2. Where the extension value SHOULD cause the AC to be rejected, the
AC verifier MUST reject the AC.
2. 拡大価値のSHOULDが西暦を拒絶させるところでは、交流検証は西暦を拒絶しなければなりません。
Farrell & Housley Standards Track [Page 23] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[23ページ]。
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. 西暦はさらなる交流検証構成に基づいて拒絶されるかもしれません。 例えば、交流検証は、ある属性を含んでいるか、または欠いている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. 交流検証がアプリケーションが西暦のコンテンツについて質問できるインタフェースを提供するなら、交流検証は構成された情報に基づいて西暦から属性をフィルターにかけるかもしれません。 例えば、交流検証は、ある属性をあるサーバに返さないように構成されるかもしれません。
6. Revocation
6. 取消し
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.
多くの環境で、西暦の有効期間は取消し情報を発行して、分配するのに必要である時間以下です。 したがって、短命な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つの取消し体系が定義されます、そして、交流発行人は西暦が使われる環境に最も良い合わせるものを選出するべきです。
"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拡張子は、この体系の使用を示すために西暦に存在していなければなりません。
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も存在していないところでは、交流発行人は取消し状態チェックがサポートされて、交流検証が西暦の取消し状態を確立するのを許容するために何らかの取消しメソッドを提供しなければならないとそれとなく述べています。
"Pointer in AC" scheme:
「西暦の指針」体系:
ACs may "point" to sources of revocation status information, using
either an authorityInfoAccess extension or a crlDistributionPoints
extension within the AC.
ACsは取消し状態情報の源に「指すかもしれません」、西暦の中でauthorityInfoAccess拡張子か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.
交流ユーザにとって、「決して取り消さないでください」という体系は、サポートされて「西暦の指針」体系SHOULDであるに違いありません。サポートされます。 「決して取り消さないでください」という体系だけがサポートされるなら、それがするすべてのACsはnoRevAvail拡張子を含んでいなくて、拒絶しなければなりません。
Farrell & Housley Standards Track [Page 24] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[24ページ]。
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.
交流発行人において、「決して取り消さないでください」という体系をサポートしなければなりません。 かつてそうするすべてのACsがその交流発行人によって発行されて、noRevAvail拡張子を含んでいるなら、「西暦の指針」体系はサポートされる必要はありません。 何かnoRevAvail拡張子を含まない西暦を発行できるなら、「西暦の指針」体系をサポートしなければなりません。
An AC MUST NOT contain both a noRevAvail and a "pointer in AC".
西暦はnoRevAvailと「西暦の指針」の両方を含んではいけません。
An AC verifier MAY use any source for AC revocation status information.
交流検証は交流取消し状態情報にどんなソースも使用するかもしれません。
7. Optional Features
7. オプション機能
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.
このセクションは実装されるかもしれない特徴を指定します。 このプロフィールへの順応はこれらの特徴に支持を要しません。 しかしながら、これらの特徴を提供するなら、以下で説明されるとしてそれらを提供しなければなりません。
7.1 Attribute Encryption
7.1 属性暗号化
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.
そして、西暦ではっきりとアプリケーション・プロトコル以内か西暦がレガシーアプリケーションユーザ名/パスワードのような何らかの機密情報を含むところまで運ばれるところでは、交流属性の暗号化が必要であるかもしれません。
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.
1セットの属性が西暦、Cryptographic Message Syntaxの中で暗号化されることであるときに、EnvelopedData構造[CMS]は、情報を合わせながら暗号文と関連受取人を運ぶのに使用されます。
This type of attribute encryption is targeted. Before the AC is signed, the attributes are encrypted for a set of predetermined recipients.
このタイプの属性暗号化は狙います。 西暦が署名される前に、属性は1セットの予定された受取人のために暗号化されます。
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.
そして、西暦は署名しているデータに暗号文を含んでいます。 EnvelopedData(イド-envelopedData)ContentTypeは使用されています、そして、満足している分野はEnvelopedDataタイプを含むでしょう。
The ciphertext is included in the AC as the value of an encAttrs attribute. Only one encAttrs attribute can be present in an AC; however, the encAttrs attribute MAY be multi-valued, and each of its values will contain an independent EnvelopedData.
暗号文はencAttrs属性の値として西暦に含まれています。 1つのencAttrs属性だけが西暦に存在している場合があります。 しかしながら、encAttrs属性はマルチ評価されているかもしれません、そして、それぞれの値は独立しているEnvelopedDataを含むでしょう。
Each value can contain a set of attributes (each possibly a multi- valued attribute) encrypted for a set of predetermined recipients.
各値が1セットの属性を含むことができる、(それぞれ、ことによるとマルチ評価された属性) 1セットの予定された受取人のために、暗号化されています。
Farrell & Housley Standards Track [Page 25] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[25ページ]。
The cleartext that is encrypted has the type:
暗号化されたcleartextには、タイプがあります:
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ACClearAttrs:、:= 系列acIssuer GeneralName、acSerial INTEGER、attrs SEQUENCE OF Attribute
The DER encoding of the ACClearAttrs structure is used as the encryptedContent field of the EnvelopedData. The DER encoding MUST be embedded in an OCTET STRING.
ACClearAttrs構造のDERコード化はEnvelopedDataのencryptedContent分野として使用されます。 DERコード化をOCTET STRINGに埋め込まなければなりません。
The acIssuer and acSerial fields are present to prevent ciphertext stealing. When an AC verifier has successfully decrypted an encrypted attribute, it MUST then check that the AC issuer and serialNumber fields contain the same values. This prevents a malicious AC issuer from copying ciphertext from another AC (without knowing its corresponding plaintext).
acIssuerとacSerial分野は、暗号文が横取りするのを防ぐために存在しています。 交流検証が首尾よく暗号化された属性を解読したなら、交流発行人とserialNumber分野が同じ値を含んでいるのはチェックしなければなりません。 これは、悪意がある交流発行人が暗号文を別の西暦(対応する平文を知っていることのない)を回避するのを防ぎます。
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):
属性を暗号化するとき、交流発行人のための手順は以下によって例証されます(同じ結果を与えるいかなる他の手順も用いられるかもしれません):
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. このセットの受取人へのデータのためにEnvelopedData構造を作成してください。 2.2. encAttrs属性の値としてEnvelopedDataを含むContentInfoをコード化してください。 2.3. cleartext属性が署名している西暦に存在していないのを確実にしてください。 3. encAttrs(複数の値がある)を西暦に加えてください。
Note that there may be more than one attribute of the same type (the same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain the same attribute type both in clear and in encrypted form (and indeed several times if the same recipient is associated with more than one EnvelopedData). One approach implementers may choose, would be to merge attribute values following decryption in order to re- establish the "once only" constraint.
同じタイプ(同じOBJECT IDENTIFIER)の1つ以上の属性が復号化の後にあるかもしれないことに注意してください。 すなわち、西暦がともに明確で中に暗号化されたフォームに同じ属性タイプを含むかもしれない、(本当に、何度か、同じ受取人が1EnvelopedDataに関連している、) 1アプローチimplementersが選ばれるかもしれなくて、「かつて唯一」の規制を再確立するために復号化に続いて、属性値を合併することになっているでしょう。
name id-aca-encAttrs
OID { id-aca 6}
Syntax ContentInfo
values Multiple Allowed
イド-aca-encAttrs OIDイド-aca6構文ContentInfo値をMultiple Allowedと命名してください。
Farrell & Housley Standards Track [Page 26] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[26ページ]。
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.
西暦が交流検証のために明らかに暗号化された属性を含んでいるなら、復号化プロセスは失敗してはいけません。 復号化が失敗するなら、西暦を拒絶しなければなりません。
7.2 Proxying
7.2 Proxying
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.
サーバが別のサーバのためのクライアントとして交流所有者を代表して機能するとき、サーバはプロキシに西暦を必要とするかもしれません。 交流発行人のコントロールの下でそのようなproxyingをしなければならないかもしれません、あらゆる西暦がどんなproxiableであるというわけではなく、与えられたproxiable西暦を狙っているファッションでproxiedされることができるように。 また、プロキシ(1つ以上の中間的サーバがある)のチェーンのサポートが必要であるかもしれません。 これが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.
この拡大が存在しているとき、交流検証は、西暦が受け取られた実体がそれを送ることができて、西暦がこの検証で使用できるのをチェックしなければなりません。
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).
proxying情報は1セットのプロキシ情報から成ります。それはそれぞれ情報を狙うセットです。 同じプロキシセットでともに西暦の検証と送付者を命名するなら、西暦を受け入れることができます(正確な規則を以下に与えます)。
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.
効果は交流所有者が有効な次に、それ自体と同じプロキシセットの1つにはある目標へのプロキシしかそうすることができないどんな目標にも西暦を送ることができるということです。
The following data structure is used to represent the targeting/proxying information.
以下のデータ構造は、狙い/proxying情報を表すのに使用されます。
ProxyInfo ::= SEQUENCE OF Targets
ProxyInfo:、:= 目標の系列
As in the case of targeting, the targetCert CHOICE MUST NOT be used.
狙いに関するケースのように、targetCert CHOICEは使用されているはずがありません。
A proxy check succeeds if either one of the conditions below is met:
以下の状態のどちらかが会われるなら、プロキシチェックは成功します:
1. The identity of the sender, as established by the underlying
authentication service, matches the holder field of the AC, and
the current server "matches" any one of the proxy sets. Recall
that "matches" is as defined section 4.3.2.
1. 基本的な認証サービスで確立される送付者のアイデンティティは西暦の所有者分野に合っています、そして、現在のサーバはプロキシセットのいずれにも「合わせています」。 定義されたセクション4.3.2として「マッチ」があったと思い出してください。
Farrell & Housley Standards Track [Page 27] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[27ページ]。
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は基本的な認証サービスで設立されるようにセットします、そして、(それをセット「A」と呼んでください)現在のサーバはセット「A」のtargetName分野の1つであるか現在のサーバがセット「A」のtargetGroup分野の1つのメンバーです。
When an AC is proxied more than once, a number of targets will be on the path from the original client, which is normally, but not always, the AC holder. In such cases, prevention of AC "stealing" requires that the AC verifier MUST check that all targets on the path are members of the same proxy set. It is the responsibility of the AC- using protocol to ensure that a trustworthy list of targets on the path is available to the AC verifier.
西暦が一度よりproxiedされるとき、多くの目標がオリジナルのクライアントからの経路にあるでしょう、交流所有者。(通常である経路はいつもそうであるというわけではありません)。 そのような場合、「横取り交流」の防止は、交流検証が、経路のすべての目標が同じプロキシセットのメンバーであることをチェックしなければならないのを必要とします。 経路の目標の信頼できるリストが交流検証に利用可能であることを保証するのは、西暦がプロトコルを使用する責任です。
name id-pe-ac-proxying
OID { id-pe 10 }
syntax ProxyInfo
criticality MUST be TRUE
名前イド-pe-ac-proxying OIDイド-pe10構文ProxyInfoの臨界はTRUEであるに違いありません。
7.3 Use of ObjectDigestInfo
7.3 ObjectDigestInfoの使用
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.
いくつかの環境で、西暦がアイデンティティ(entityNameを通した)、または、PKC(baseCertificateIDを通した)にリンクされないのが必要であるかもしれません。 所有者分野のobjectDigestInfo CHOICEはこの要件のサポートを許します。
If the holder is identified with the objectDigestInfo field, then the AC version field MUST contain v2 (the integer 1).
所有者がobjectDigestInfo分野と同一視されているなら、交流バージョン分野は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.
考えはそのオブジェクトのハッシュを西暦の所有者分野に置くことによって西暦をオブジェクトにリンクすることです。 例えば、これは名前よりむしろ公開鍵にリンクされるACsの生産を許します。 また、それはJavaのクラスなどの実行可能なオブジェクトに関連している特権を含むACsの生産を許します。 しかしながら、このプロフィールは公開鍵かPKCの上でハッシュを使用する方法を指定するだけです。 すなわち、conformant 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.
西暦を公開鍵にリンクするために、その存在している公開鍵の表現に関してPKCでハッシュについて計算しなければならなくて、明確に、ハッシュアルゴリズムのための入力はキーのSubjectPublicKeyInfo表現のDERコード化であるに違いありません。 以下に注意してください。 これはBIT STRINGと同様にAlgorithmIdentifierを含んでいます。 キーをコード化するために[PKIXPROF]で与えられた規則に従わなければなりません。 この場合、digestedObjectTypeはpublicKeyであるに違いありません、そして、otherObjectTypeID分野は存在しているはずがありません。
Farrell & Housley Standards Track [Page 28] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[28ページ]。
Note that if the public key value used as input to the hash function has been extracted from a PKC, it is possible that the SubjectPublicKeyInfo from that PKC is NOT the value which should be hashed. This can occur if DSA Dss-parms are inherited as described in section 7.3.3 of [PKIXPROF]. The correct input for hashing in this context will include the value of the parameters inherited from the CA's PKC, and thus may differ from the SubjectPublicKeyInfo present in the PKC.
ハッシュ関数に入力されるように使用される公開鍵値がPKCから抽出されたなら、そのPKCからのSubjectPublicKeyInfoが論じ尽くされるべきである値でないことが可能であることに注意してください。 DSA Dss-parmsが.3セクション7.3[PKIXPROF]で説明されるように引き継ぐなら、これは起こることができます。 論じ尽くす正しい入力は、このような関係においてはCA PKCから引き継がれたパラメタの値を含んで、その結果、PKCにおける現在のSubjectPublicKeyInfoと異なるかもしれません。
Implementations which support this feature MUST be able to handle the representations of public keys for the algorithms specified in section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present.
この特徴をサポートする実装は[PKIXPROF]のセクション7.3で指定されたアルゴリズムのために公開鍵の表現を扱うことができなければなりません。 この場合、digestedObjectTypeはpublicKeyであるに違いありません、そして、otherObjectTypeID分野は存在しているはずがありません。
In order to link an AC to a PKC via a digest, the digest MUST be calculated over the DER encoding of the entire PKC, including the signature value. In this case the digestedObjectType MUST be publicKeyCert and the otherObjectTypeID field MUST NOT be present.
ダイジェストで西暦をPKCにリンクするために、全体のPKCのDERコード化に関してダイジェストについて計算しなければなりません、署名値を含んでいて。 この場合、digestedObjectTypeはpublicKeyCertであるに違いありません、そして、otherObjectTypeID分野は存在しているはずがありません。
7.4 AA Controls
7.4 AAコントロール
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.
交流合法化の間、信用パーティーは質問に答えなければなりません: この交流発行人はこの属性を含む問題ACsに任せられますか? AAControls PKC拡張子は、質問に答えるのを助けるのに使用されるかもしれません。 カリフォルニアと交流発行人PKCsにAAControls拡張子が使用されることを意図します。
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
イド-pe-aaControlsオブジェクト識別子:、:= イド-pe6
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AAControls:、:= 系列pathLenConstraint整数(0..MAX)の任意の、そして、permittedAttrs[0]AttrSpec任意の、そして、excludedAttrs[1]AttrSpec任意のpermitUnSpecified論理演算子は本当にデフォルトとします。
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
AttrSpec:、:= オブジェクト識別子の系列
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(PKCsにAAControlsを含んでいると直接信じられたカリフォルニア)と、交流発行人の間の許容距離を制限します。
The permittedAttrs field specifies a set of attribute types that any AC issuer below this AA CA is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly allowed.
permittedAttrs分野はこのAA CAの下のどんな交流発行人もACsに含むことができる1セットの属性タイプを指定します。 この分野が存在していないなら、それは、属性タイプが全く明らかに許容されていないことを意味します。
Farrell & Housley Standards Track [Page 29] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[29ページ]。
The excludedAttrs field specifies a set of attribute types that no AC issuer is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly disallowed.
excludedAttrs分野はどんな交流発行人もACsに含むことができない1セットの属性タイプを指定します。 この分野が存在していないなら、それは、属性タイプが全く明らかに禁じられないことを意味します。
The permitUnSpecified field specifies how to handle attribute types which are not present in either the permittedAttrs or excludedAttrs fields. TRUE (the default) means that any unspecified attribute type is allowed in ACs; FALSE means that no unspecified attribute type is allowed.
permitUnSpecified分野はpermittedAttrsかexcludedAttrsがさばくどちらかで出席していない属性タイプを扱う方法を指定します。 TRUE(デフォルト)は、どんな不特定の属性タイプもACsに許容されていることを意味します。 FALSEは、どんな不特定の属性タイプも許容されていないことを意味します。
When AAControls are used, the following additional checks on an AA's PKC chain MUST all succeed for the AC to be valid:
AAControlsが使用されているとき、AAのPKCチェーンにおける以下の追加チェックは西暦が有効であるようにすべて成功しなければなりません:
1. Some CA on the ACs certificate path MUST be directly trusted to
issue PKCs which precede the AC issuer in the certification path;
call this CA the "AA CA".
1. 証明経路で交流発行人に先行するPKCsを発行すると直接ACs証明書経路のいくつかのカリフォルニアを信じなければなりません。 「AAカリフォルニア」にこのカリフォルニアに電話をしてください。
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. 交流発行人のPKCをダウンして、含むAA CAからの経路のすべてのPKCsが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から交流発行人までのPKCsのすべてのAAControls拡大値のすべてに従って許容されているそれらの属性だけを使用してもよいです。 他のすべての属性を無視しなければなりません。 属性復号化に続く属性のセットにこのチェックを適用しなければなりません、そして、また、イド-aca-encAttrsタイプをチェックしなければなりません。
name id-pe-aaControls
OID { id-pe 6 }
syntax AAControls
criticality MAY be TRUE
名前イド-pe-aaControls OIDイド-pe6構文AAControlsの臨界はTRUEであるかもしれません。
8. Security Considerations
8. セキュリティ問題
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.
秘密鍵のために提供された保護は警備を維持することにおいて重要な要素です。 交流発行人がそれらの秘密鍵を保護しないと、攻撃者がそれらのふりをすることを許可するでしょう、偽のACsか取消しが状態であると潜在的に生成して。 にせのACsと取消し状態の存在はシステムにおける信用を損ねるでしょう。 感染が検出されるなら、交流発行人によって発行されたすべてのACsを取り消さなければなりません。 そのような感染が問題が多くなった後に再建によって、交流発行人がそのようなインシデントを避けるために強い技術的な程度(例えば、耐タンパー性の暗号のモジュール)と適切な管理手順(例えば、義務の分離)の組み合わせを実装するように教えられます。
Farrell & Housley Standards Track [Page 30] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[30ページ]。
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.
また、交流発行人の個人的な署名キーの損失も問題が多いかもしれません。 交流発行人は、取消し状態を作り出すことができませんし、交流更新を実行できないでしょう。 交流発行人が署名キーのために安全なバックアップを維持するように教えられます。 主要なバックアップ手順のセキュリティは主要な感染を避けることにおいて重要な要素です。
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.
取消し状態の有用性と新しさは長命の西暦に置かれるべきである保証の度合いに影響するでしょう。 長命のACsは自然に期限が切れますが、イベントは生まれながらの生涯起こるかもしれません(交流所有者と属性の間の結合を否定します)。 取消し状態がタイミングが悪いか、または入手できないなら、結合に関連している保証は明確に抑えられます。
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.
交流所有者と属性の間の結合は暗号のモジュール実装とアルゴリズムが以前はよく署名を生成していたより強いはずがありません。 短いキー長か弱いハッシュアルゴリズムが西暦に関するユーティリティを制限するでしょう。 注意する発行人が奨励される西暦は、強い暗号のテクニックを使うことができるように暗号理論で進みます。
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.
名前比較規則の無節操な適用は狙う病人かproxied ACsの承認、または有効なものの拒絶をもたらすかもしれません。 仕様のX.500シリーズは分類名を比較するための規則を定義します。 これらの規則はケースに入れる関係も、文字集合も、マルチキャラクタ余白サブストリングも、または主で引きずっている余白なしでストリングの比較を必要とします。 2進の比較に最小限で支持を要して、この仕様と[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.
交流発行人は同様に交流holder.entityName分野で所有者のPKCで分類名を分類名にコード化しなければなりません。 異なったencodingsが使用されているなら、この仕様の実装は、西暦、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.
属性証明書がHolder分野のbaseCertificateIDの部品を使用することで所有者のPKCに結ばれて、使用中のPKIが同じ発行人名がbaseCertificateIDの部品で指定されている凶暴なカリフォルニアを含めるなら、この凶暴なカリフォルニアは悪意があるパーティーにPKCを発行するかもしれません、適切な所有者のPKCとして同じ発行人名と通し番号を使用して。 そして、悪意があるパーティーは西暦に関連してこのPKCを使用できました。 同じ名前がある2CAsがあるはずがないように適切に管理することによって避けられて、PKIを構成するこのシナリオSHOULD。 別の代替手段はObjectDigestInfo分野でpublicKeyCertタイプを使用することでACsをPKCsに結ぶことです。 これに失敗して、交流検証は、潜在的衝突が実際に起こることができないと証明しなければなりません(他の手段を使用します)、例えば、かかわったCAsのCPSsはどんなそのような名前衝突も起こることができないと断言するかもしれません。
Farrell & Housley Standards Track [Page 31] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[31ページ]。
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.
Implementersは、西暦の合法化に続いて、発行人が発行すると信じられる属性だけが承認決定に使用されるのを確実にしなければなりません。 他の属性。(その属性はプレゼントを無視しなければならないということであるかもしれません)。 AAコントロールPKC拡張子が実装するために任意であるなら、他の手段でこの情報を交流検証に提供しなければなりません。 設定情報はありそうな代替の手段です。 交流検証が1つ以上の交流発行人を信じるなら、これは非常に重要になります。
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)によって供給された認証と交流所有者のアイデンティティの間で写像する要件がしばしばあります。 認証がPKCsを使用するなら、このマッピングは簡単です。 しかしながら、また、ACsが所有者が他の手段を使用することで認証されるかもしれない環境で使用されるのが考えられます。 Implementers SHOULD、交流所有者への認証されたアイデンティティを写像する際に非常に注意してください。
9. IANA Considerations
9. IANA問題
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.
オブジェクト識別子(OIDs)によって属性と属性証明書拡張子は特定されます。 本書では使用されるOIDsの多くがX.509[X.509-2000]からコピーされます。 他のOIDsはIANAによって代表として派遣されたアークから割り当てられました。 IANAによるさらなるどんな動作もこのドキュメントかどんな予期されたアップデートにも必要ではありません。
10. References
10. 参照
[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797,
April 2000.
[CMC] マイアーズとM.とリュウとX.とSchaadとJ.とJ.ワインスタイン、「cmの上の証明書管理メッセージ」、RFC2797、2000年4月。
[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure - Certificate Management Protocols", RFC
2510, March 1999.
[CMP] アダムスとC.とS.ファレル、「インターネットX.509公開鍵基盤--管理プロトコルを証明する」RFC2510、1999年3月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。
[KRB] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[KRB]コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[LDAP]ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
Farrell & Housley Standards Track [Page 32] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[32ページ]。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "X.509 Internet Public Key Infrastructure -
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[OCSP] マイアーズとM.とAnkneyとR.とMalpaniとA.とガリペリンとS.とC.アダムス、「公開鍵基盤--オンライン証明書状態プロトコル--X.509インターネットOCSP」、RFC2560 1999年6月。
[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Lists CRL Profile", RFC 3279, April 2002.
[PKIXALGS]Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤のためのアルゴリズムと識別子は、CRLが輪郭を描く取消しリストを証明して、証明します」、RFC3279、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.とポークとTとフォードとW.と独奏、D.、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィール」、RFC3280、2002年4月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ・リー、T.、Masinter L.、およびM. McCahill、「Uniform Resource Locator(URL)」、RFC1738、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
Farrell & Housley Standards Track [Page 33] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[33ページ]。
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である値に従ったアーク要素を持っているOIDsのためにサポートするこの仕様、(0〜42億9496万7295が包括的であったなら、すなわち、それらはそうしなければなりません)、SHOULD、2未満^31になってください(すなわち、21億4748万3647以下)。 これは、それぞれのアーク要素が32ビットのただ一つの単語の中に表されるのを許容します。 また、実装は(包括的)でドット付き10進法([LDAP]、セクション4.1.2を見る)ストリング表現の長さが最大100バイトであるかもしれないOIDsをサポートしなければなりません。 最大20の要素が(包括的)で実装はOIDsを扱うことができなければなりません。 AAのSHOULD NOTはこれらの要件を破るOIDsを含むACsを発行します。
The following OIDs are imported from [PKIXPROF]:
以下のOIDsは[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 }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)、イドモッズOBJECT IDENTIFIER:、:= イド-pkix0、イド-pe OBJECT IDENTIFIER:、:= イド-pkix1イド広告OBJECT IDENTIFIER:、:= イド-pkix48、イド、-、OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)4、イドCe OBJECT IDENTIFIER:、:= 共同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 }
イドモッズ属性本命OBJECT IDENTIFIER:、:= イドモッズ12
The following AC extension OIDs are defined:
以下の交流拡大OIDsは定義されます:
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 }
イド-pe-ac-auditIdentityオブジェクト識別子:、:= イド-pe4、イド-pe-ac-proxying OBJECT IDENTIFIER:、:= イド-pe10、イドCe targetInformation OBJECT IDENTIFIER、:、:= イドCe55
The following PKC extension OIDs are defined:
以下のPKCの拡大OIDsは定義されます:
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
イド-pe-aaControlsオブジェクト識別子:、:= イド-pe6
Farrell & Housley Standards Track [Page 34] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[34ページ]。
The following attribute OIDs are defined:
以下の属性OIDsは定義されます:
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) }
イド-aca OBJECT IDENTIFIER:、:= イド-pkix10、イド-aca-authenticationInfo OBJECT IDENTIFIER:、:= イド-aca1、イド-aca-accessIdentity OBJECT IDENTIFIER:、:= イド-aca2、イド-aca-chargingIdentity OBJECT IDENTIFIER:、:= イド-aca3イドacaグループOBJECT IDENTIFIER:、:= イド-aca4、イド-aca-encAttrs OBJECT IDENTIFIER:、:= 役割におけるイド-aca6イドOBJECT IDENTIFIER:、:= イド、-、72、クリアランスのイドOBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)のモジュールの(1)の選択された属性タイプ(5)クリアランス(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)}
PKIXAttributeCertificateiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ属性本命(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)}
-- IMPORTedモジュールOIDsは、[PKIXPROF]が変化するかどうかを変えるかもしれません--PKIX Certificate Extensions Attribute、AlgorithmIdentifier、CertificateSerialNumber、Extensions(UniqueIdentifier)はイドでpkixします、イド-pe、イド-kp、イド広告、イド、-、FROM PKIX1Explicit88iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な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)} ;
GeneralName、GeneralNames、イドCeのFROM PKIX1Implicit88のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)イドpkix1内在している88(2)。
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
イド-pe-ac-auditIdentityオブジェクト識別子:、:= イド-pe4、イド-pe-aaControls OBJECT IDENTIFIER:、:= イド-pe6、イド-pe-ac-proxying OBJECT IDENTIFIER:、:= イド-pe10、イドCe targetInformation OBJECT IDENTIFIER、:、:= イドCe55
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
イド-aca OBJECT IDENTIFIER:、:= イド-pkix10
Farrell & Housley Standards Track [Page 35] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[35ページ]。
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 }
イド-aca-authenticationInfoオブジェクト識別子:、:= イド-aca1、イド-aca-accessIdentity OBJECT IDENTIFIER:、:= イド-aca2、イド-aca-chargingIdentity OBJECT IDENTIFIER:、:= イド-aca3イドacaグループOBJECT IDENTIFIER:、:= イド-aca4--イド-aca5は予約されたイド-aca-encAttrs OBJECT IDENTIFIERです:、:= イド-aca6
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) }
役割におけるイドOBJECT IDENTIFIER:、:= イド、-、72、クリアランスのイドOBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)のモジュールの(1)の選択された属性タイプ(5)クリアランス(55)
-- Uncomment this if using a 1988 level ASN.1 compiler
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- Uncomment、a1988を使用するなら、これはASN.1コンパイラを平らにします--、UTF8String:、:= [普遍的な12]内在している八重奏ストリング
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificate:、:= 系列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
}
AttributeCertificateInfo:、:= 系列バージョンAttCertVersion、--バージョンはv2です、所有者Holder、発行人AttCertIssuer、署名AlgorithmIdentifier、serialNumber CertificateSerialNumber、attrCertValidityPeriod AttCertValidityPeriod、属性SEQUENCE OF Attribute、issuerUniqueID UniqueIdentifier OPTIONAL、拡大Extensions OPTIONAL
AttCertVersion ::= INTEGER { v2(1) }
AttCertVersion:、:= 整数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
}
所有者:、:= 系列baseCertificateID[0]IssuerSerial OPTIONAL(--所有者のPublic Key Certificate entityName[1]GeneralNames OPTIONAL--名(主張者か役割のobjectDigestInfo[2]ObjectDigestInfo OPTIONAL)の発行人と通し番号)が直接以前はよく認証していた、--例えば、所有者、実行可能
Farrell & Housley Standards Track [Page 36] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[36ページ]。
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
}
ObjectDigestInfo:、:= 系列digestedObjectType ENUMERATED、このプロフィールotherObjectTypeID OBJECT IDENTIFIER OPTIONALでpublicKey(0)、publicKeyCert(1)、otherObjectTypesがそうしてはいけないというotherObjectTypes(2)を使用してはいけません、digestAlgorithm AlgorithmIdentifier、objectDigest BIT STRING
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
AttCertIssuer:、:= 選択{v1Form GeneralNames(これで使用されてはいけない)はv2Form[0]V2Formの輪郭を描きます--v2専用}
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
}
V2Form:、:= 系列issuerName GeneralNames OPTIONAL、baseCertificateID[0]IssuerSerial OPTIONAL、objectDigestInfo[1]ObjectDigestInfo OPTIONAL--issuerNameはこのプロフィールに存在していなければなりません--baseCertificateIDとobjectDigestInfoはそうしなければなりません--、このプロフィールでは、存在していません。
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
IssuerSerial:、:= 系列発行人GeneralNames、連続のCertificateSerialNumber、issuerUID UniqueIdentifier OPTIONAL
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
AttCertValidityPeriod:、:= 系列notBeforeTime GeneralizedTime、notAfterTime GeneralizedTime
Targets ::= SEQUENCE OF Target
目標:、:= 目標の系列
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
以下を狙ってください:= 選択targetName[0]GeneralName、targetGroup[1]GeneralName、targetCert[2]TargetCert
Farrell & Housley Standards Track [Page 37] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[37ページ]。
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
TargetCert:、:= 系列targetName GeneralName任意の、そして、certDigestInfo ObjectDigestInfo任意のtargetCertificate IssuerSerial
IetfAttrSyntax ::= SEQUENCE {
policyAuthority[0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
IetfAttrSyntax:、:= 系列policyAuthority[0] GeneralNames OPTIONAL、値のSEQUENCE OF CHOICE、八重奏OCTET STRING(oid OBJECT IDENTIFIER)はUTF8Stringを結びます。
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
SvceAuthInfo:、:= 系列サービスGeneralName、ident GeneralName、authInfo OCTET STRING OPTIONAL
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
RoleSyntax:、:= 系列任意のroleAuthority[0]GeneralNames roleName[1]GeneralName
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories
[2] SET OF SecurityCategory OPTIONAL
}
クリアランス:、:= 系列policyId[0]オブジェクト識別子、ClassListデフォルトが非分類したclassList[1]、[2]が設定したSecurityCategory任意のsecurityCategories
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
ClassList:、:= ビット列無印の(0)、(1)、部外秘な(2)、秘密の(3)、秘密(4)、topSecret(5)を非分類しました。
SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
SecurityCategory:、:= 系列[0] IMPLICIT OBJECT IDENTIFIERをタイプしてください、そして、値[1]ANY DEFINED BYはタイプします。
Farrell & Housley Standards Track [Page 38] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[38ページ]。
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AAControls:、:= 系列pathLenConstraint整数(0..MAX)の任意の、そして、permittedAttrs[0]AttrSpec任意の、そして、excludedAttrs[1]AttrSpec任意のpermitUnSpecified論理演算子は本当にデフォルトとします。
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
AttrSpec:、:= オブジェクト識別子の系列
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ACClearAttrs:、:= 系列acIssuer GeneralName、acSerial INTEGER、attrs SEQUENCE OF Attribute
ProxyInfo ::= SEQUENCE OF Targets
ProxyInfo:、:= 目標の系列
END
終わり
Author's Addresses
作者のアドレス
Stephen Farrell Baltimore Technologies 39/41 Parkgate Street Dublin 8 IRELAND
スティーブンファレルボルチモア技術39/41Parkgate通りダブリン8アイルランド
EMail: stephen.farrell@baltimore.ie
メール: stephen.farrell@baltimore.ie
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley RSA研究所918は小山Driveヴァージニア20170ハーンドン(米国)を跳ばせます。
EMail: rhousley@rsasecurity.com
メール: rhousley@rsasecurity.com
Acknowledgements
承認
Russ Housley thanks the management at SPYRUS, who supported the development of this specification while he was employed at SPYRUS. Russ Housley also thanks the management at RSA Laboratories, who supported the completion of the specification after a job change.
ラスHousleyはSPYRUSで管理に感謝します。(SPYRUSは彼がSPYRUSで雇われましたが、この仕様の開発をサポートしました)。 また、ラスHousleyはRSA研究所で管理に感謝します。(研究所は転職の後に仕様の完成をサポートしました)。
Farrell & Housley Standards Track [Page 39] RFC 3281 An Internet Attribute Certificate April 2002
ファレルとHousley規格はインターネット属性証明書2002年4月にRFC3281を追跡します[39ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Farrell & Housley Standards Track [Page 40]
ファレルとHousley標準化過程[40ページ]
一覧
スポンサーリンク
