RFC4476 日本語訳
4476 Attribute Certificate (AC) Policies Extension. C. Francis, D.Pinkas. May 2006. (Format: TXT=20229 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Francis
Request for Comments: 4476 Raytheon
Category: Standards Track D. Pinkas
Bull
May 2006
コメントを求めるワーキンググループC.フランシスの要求をネットワークでつないでください: 4476年のレイセオンカテゴリ: 標準化過程D.ピンカス雄牛2006年5月
Attribute Certificate (AC) Policies Extension
属性証明書(西暦)方針拡張子
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs.
このドキュメントは明らかに与えられたAttribute Certificate(西暦)に適用するAttribute Certificate Policies(ACPs)を述べる1つの証明書拡張子について説明します。 このドキュメントの目標は1特定のACPsの参照に基づいていくつかの属性を運ぶ与えられた西暦を受け入れることができるか否かに関係なく、すなわち、西暦を有効にするときの評価する追加テストを実行するために信用にパーティーを許容することです。
Francis & Pinkas Standards Track [Page 1] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[1ページ]。
1. Introduction
1. 序論
When issuing a Public Key Certificate (PKC), a Certificate Authority (CA) can perform various levels of verification with regard to the subject identity (see [RFC3280]). A CA makes its verification procedures, as well as other operational rules it abides by, "visible" through a certificate policy, which may be referenced by a certificate policies extension in the PKC.
Public Key Certificate(PKC)を発行するとき、Certificate Authority(カリフォルニア)は対象のアイデンティティに関して様々なレベルの検証を実行できます([RFC3280]を見てください)。 カリフォルニアは検証手続を作ります、それが守る他の操作上の規則と同様に、証明書方針で「目に見えます」。(PKCにおける証明書方針拡張子でそれは、参照をつけられるかもしれません)。
The purpose of this document is to define an Attribute Certificate (AC) policies extension able to explicitly state the AC policies that apply to a given AC, but not the AC policies themselves. Attribute Certificates are defined in [RFC3281].
このドキュメントの目的は明らかに交流方針自体ではなく、与えられた西暦に適用される交流方針を述べることができるAttribute Certificate(西暦)方針拡張子を定義することです。 属性Certificatesは[RFC3281]で定義されます。
1.1. Conventions Used in This Document
1.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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. AC Policies Extension Semantics
2. 交流方針拡大意味論
An Attribute Certificate Policy is a named set of rules that indicates the applicability of an AC to a particular community and/or class of applications with common security requirements. It defines rules for the generation, issuance, and revocation of ACs. It may also include additional rules for attributes registration.
Attribute Certificate Policyは共通の安全保障要件で特定の共同体、そして/または、クラスのアプリケーションへの西暦の適用性を示す命名されたセットの規則です。 それはACsの世代、発行、および取消しのための規則を定義します。 また、それは属性登録のための付則を含むかもしれません。
Thus, note that an Attribute Authority (AA) does not necessarily support one single ACP. However, for each AC that is delivered, the AA SHALL make sure that the policy applies to all the attributes that are contained in it.
したがって、Attribute Authority(AA)が必ず1独身のACPをサポートするというわけではないことに注意してください。 しかしながら、提供される各西暦に関して、AA SHALLは、方針がそれに含まれているすべての属性に適用されるのを確実にします。
An ACP may be used by an AC user to decide whether or not to trust the attributes contained in an AC for a particular purpose.
ACPは、特定の目的のために西暦に含まれた属性を信じるかどうか決めるのに交流ユーザによって使用されるかもしれません。
When an AC contains an AC policies extension, the extension MAY, at the option of the AA, be either critical or non-critical.
西暦がAAの選択のときに交流方針拡大を含むとき、拡大は、重要であるか、または非臨界であるかもしれません。
The AC Policies extension MAY be included in an AC. Like all X.509 certificate extensions [X.509], the AC policies extension is defined using ASN.1 [ASN1]. See Appendix A.
交流Policies拡張子は西暦に含まれるかもしれません。 すべてのX.509が拡大[X.509]を証明するように、交流方針拡大はASN.1[ASN1]を使用することで定義されます。 付録Aを見てください。
The definitions are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 syntax used in the most recent ISO/IEC/ITU-T standards.
定義は最新のITU ISO/IEC/T規格に使用される1997ASN.1構文よりむしろ1988の抽象的なSyntax Notation One(ASN.1)に提示されます。
The AC policies extension is identified by id-pe-acPolicies.
交流方針拡大はイド-pe-acPoliciesによって特定されます。
Francis & Pinkas Standards Track [Page 2] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[2ページ]。
id-pe-acPolicies OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-pe(1) 15 }
イド-pe-acPoliciesオブジェクト識別子:、:= iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)イド-pkix(7)イド-pe(1)15
The AC policies extension includes a list of AC policies recognized by the AA that apply to the attributes included in the AC.
交流方針拡大は西暦に属性を含んでいるのに適用するAAによって認識された交流方針のリストを含んでいます。
AC Policies may be defined by any organization with a need. Object identifiers used to identify AC Policies are assigned in accordance with [X.660|ISO9834-1].
交流Policiesは必要性があるどんな組織によっても定義されるかもしれません。 [X.660| ISO9834-1]に従って、交流Policiesを特定するのに使用されるオブジェクト識別子は割り当てられます。
The AC policies extension in an AC indicates the AC policies for which the AC is valid.
西暦での交流方針拡大は西暦が有効である交流方針を示します。
An application that recognizes this extension and its content SHALL process the extension regardless of the value of the criticality flag.
この拡大を認識するアプリケーションとその満足しているSHALLは臨界旗の値にかかわらず拡大を処理します。
If the extension is both flagged non-critical and not recognized by the AC-using application, then the application MAY ignore it.
拡大であるなら、旗を揚げられた両方が非臨界です、そして、次に、西暦を使用するアプリケーションで認識されていなくて、アプリケーションはそれを無視するかもしれません。
If the extension is marked critical or is recognized by the AC-using application, it indicates that the attributes contained in the attribute certificate SHALL only be used for the purpose, and in accordance with the rules associated with one of the indicated AC policies. If none of the ACP identifiers is adequate for the application, then the AC MUST be rejected.
拡大が重要であるとマークされるか、または西暦を使用するアプリケーションで認められるなら、それは、目的、および示された交流方針の1つに関連している規則に従って属性証明書SHALLに含まれた属性が使用されるだけであるのを示します。 アプリケーションには、ACP識別子のいずれも適切でないなら、西暦を拒絶しなければなりません。
If the extension is marked critical or is recognized by the AC using application, the AC-using application MUST use the list of AC policies to determine whether it is appropriate to use the attributes contained in that AC for a particular transaction. When the appropriate policy is not found, the AC SHALL be rejected.
拡大がアプリケーションを使用することで重要であるとマークされるか、または西暦によって認められるなら、西暦を使用するアプリケーションは、特定の取引のためにその西暦に含まれた属性を使用するのが適切であるかどうか決定するのに交流方針のリストを使用しなければなりません。 適切な方針が見つけられないときAC SHALL、拒絶されてください。
2.1. AC Policy Extension Syntax
2.1. 交流方針拡大構文
The syntax for the AC Policy extension is:
交流Policy拡張子のための構文は以下の通りです。
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
AcPoliciesSyntax:、:= PolicyInformationの系列サイズ(1..MAX)
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL}
PolicyInformation:、:= 系列policyIdentifier AcPolicyId、PolicyQualifierInfo任意のpolicyQualifiers系列サイズ(1..MAX)
AcPolicyId ::= OBJECT IDENTIFIER
AcPolicyId:、:= オブジェクト識別子
Francis & Pinkas Standards Track [Page 3] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[3ページ]。
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierInfo:、:= 系列policyQualifierId PolicyQualifierId、資格を与える人いずれもDEFINED BY policyQualifierId
-- policyQualifierIds for Internet policy qualifiers
-- インターネット方針資格を与える人のためのpolicyQualifierIds
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 }
イド-qt OBJECT IDENTIFIER:、:= イド-pkix2、イド-qt-acps OBJECT IDENTIFIER:、:= イド-qt4、イド-qt-acunotice OBJECT IDENTIFIER:、:= イド-qt5
id-qt-acps OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-qt(2) 4 }
イド-qt-acps OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)イド-pkix(7)イド-qt(2)4
id-qt-acunotice OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) id-pkix(7) id-qt(2) 5 }
イド-qt-acunotice OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)イド-pkix(7)イド-qt(2)5
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
PolicyQualifierId:、:= オブジェクト識別子(イド-qt-acps| イド-qt-acunotice)
-- ACPS pointer qualifier
-- ACPS指針資格を与える人
ACPSuri ::= IA5String -- ACP statement user notice qualifier
ACPSuri:、:= IA5String--ACP声明ユーザ通知資格を与える人
ACUserNotice ::= UserNotice -- UserNotice is defined in [RFC3280]
ACUserNotice:、:= UserNotice--UserNoticeは中で定義されます。[RFC3280]
To promote interoperability, this document RECOMMENDS that policy information terms consist of only an object identifier (OID). When more than one policy is used, the policy requirements have to be non-conflicting, e.g., one policy may refine the general requirements mandated by another policy.
相互運用性を促進するために、その方針情報用語のこのドキュメントRECOMMENDSはオブジェクト識別子(OID)だけから成ります。 1つ以上の方針が使用されているとき方針要件が非闘争でなければならない、例えば、1つの方針が別の方針で強制された一般的な要件を洗練するかもしれません。
The extension defined in this specification supports two policy qualifier types for use by ACP writers and AAs. The qualifier types are the ACPS Pointer and the AC User.
この仕様に基づき定義された拡大は、2方針がACP作家とAAsによる使用のために資格を与える人タイプであるとサポートします。 資格を与える人タイプは、ACPS Pointerと交流Userです。
2.1.1. Notice Qualifiers
2.1.1. 通知資格を与える人
The ACPS Pointer qualifier contains a pointer to an Attribute Certification Practice Statement (ACPS) published by the AA. The pointer is in the form of a URI. Processing requirements for this qualifier are a local matter.
ACPS Pointer資格を与える人はAAによって発行されたAttribute Certification Practice Statement(ACPS)に指針を含みます。 指針がURIの形にあります。 この資格を与える人のための処理所要は地域にかかわる事柄です。
Francis & Pinkas Standards Track [Page 4] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[4ページ]。
The AC User Notice is intended for display to a relying party when an attribute certificate is used. The application software SHOULD display the AC User Notice of the AC. The AC User Notice is defined in [RFC3280]. It has two optional fields: the noticeRef field and the explicitText field.
属性証明書が使用されているとき、交流User Noticeはディスプレイのために信用パーティーに意図します。 アプリケーション・ソフトSHOULDは西暦の交流User Noticeを表示します。 交流User Noticeは[RFC3280]で定義されます。 それには、2つの任意の分野があります: noticeRef分野とexplicitText分野。
The noticeRef field, if used, names an organization and
identifies, by number, a particular textual statement prepared by
that organization. For example, it might identify the
organization's name and notice number 1. In a typical
implementation, the application software will have a notice file
containing the current set of notices for the AA; the application
will extract the notice text from the file and display it.
Messages MAY be multilingual, allowing the software to select the
particular language message for its own environment.
noticeRef分野は、使用されるなら組織を命名して、数に従って、その組織によって準備された特定の原文の声明を特定します。 例えば、それは組織名と通知No.1を特定するかもしれません。 典型的な実装では、アプリケーション・ソフトはAAのための現在の通知を含む通知ファイルを持つでしょう。 アプリケーションは、ファイルから通知テキストを抜粋して、それを表示するでしょう。 ソフトウェアがそれ自身の環境への特定の言語メッセージを選択するのを許容して、メッセージは多数の言語で表現されているかもしれません。
An explicitText field includes the textual statement directly in
the certificate. The explicitText field is a string with a
maximum size of 200 characters.
explicitText分野は直接証明書に原文の声明を含んでいます。 explicitText分野は200のキャラクタの最大サイズがあるストリングです。
If both the noticeRef and explicitText options are included in the one qualifier, and if the application software can locate the notice text indicated by the noticeRef option, then that text SHOULD be displayed; otherwise, the explicitText string SHOULD be displayed.
noticeRefとexplicitTextの両方であるなら、1人の資格を与える人とアプリケーション・ソフトがnoticeRefオプションで示された通知テキストの場所を見つけることができるかどうかにオプションは含まれています、テキストSHOULDを表示するその時。 さもなければ、explicitTextはSHOULDを結びます。表示します。
2.2. Attribute Certificate Policies
2.2. 属性証明書方針
The scope of this document is not the definition of the detailed content of ACPs themselves; therefore, specific policies are not defined in this document.
このドキュメントの範囲はACPs自身の詳細な内容の定義ではありません。 したがって、特定保険証券は本書では定義されません。
3. Security Considerations
3. セキュリティ問題
The ACP defined in this document applies for all the attributes that are included in one AC. AAs SHALL ensure that the ACP applies to all the attributes that are included in the ACs they issue.
本書では定義されたACPは西暦1年に含まれているすべての属性に申し込みます。 AAs SHALLは、ACPが彼らが発行するACsに含まれているすべての属性に適用するのを確実にします。
Attributes may be dynamically grouped in several ACs. It should be observed that since an AC may be issued under more than one ACP, the attributes included in a given AC MUST be compliant with all the ACPs from that AC.
属性は数個のACsでダイナミックに分類されるかもしれません。 西暦が1ACPの下で発行されるかもしれないので与えられた西暦に属性を含んでいるのがその西暦からのすべてのACPsと共に言いなりになるに違いないと認められるべきです。
When verifying an AC, a relying party MUST determine that the AC was issued by a trusted AA and then that it has the appropriate policy.
西暦について確かめるとき、信用パーティーは西暦が信じられたAAによって発行されて、その時、それには適切な方針があると決心しなければなりません。
Francis & Pinkas Standards Track [Page 5] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[5ページ]。
Failure of AAs 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, then the certificate of the AA MUST be revoked.
AAsが彼らの秘密鍵を保護しないと、攻撃者がそれらのふりをすることを許可するでしょう、偽のACsか取消しが状態であると潜在的に生成して。 にせのACsと取消し状態の存在はシステムにおける信用を損ねるでしょう。 感染は検出されて、その時はAA MUSTの証明書です。取り消されます。
Rebuilding after such a compromise will be problematic, so AAs 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.
そのような感染が問題が多くなった後に再建によって、AAsがそのようなインシデントを避けるために強い技術的な程度(例えば、耐タンパー性の暗号のモジュール)と適切な管理手順(例えば、義務の分離)の組み合わせを実装するようにアドバイスされます。
Loss of an AA's private signing key may also be problematic. The AA would not be able to produce revocation status or perform AC renewal (i.e., the issue of a new AC with the same set of attributes with the same values, for the same holder, from the same AA but with a different validity period). 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.
また、AAの個人的な署名キーの損失も問題が多いかもしれません。 AAは取消し状態を作り出すことができませんし、交流更新(すなわち、同じ所有者のための同じAAからの同じ値にもかかわらず、異なった有効期間がある同じセットの属性がある新しい西暦の問題)を実行できないでしょう。 交流発行人が署名キーのために安全なバックアップを維持するように教えられます。 主要なバックアップ手順のセキュリティは主要な感染を避けることにおいて重要な要素です。
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 an AC's natural lifetime that negate the binding between the AC holder and the attributes. If revocation status is untimely or unavailable, the assurance associated with the binding is clearly reduced.
取消し状態の有用性と新しさは長命の西暦に置かれるべきである保証の度合いに影響するでしょう。 長命の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. AAs are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
交流所有者と属性の間の結合は暗号のモジュール実装とアルゴリズムが以前はよく署名を生成していたより強いはずがありません。 短いキー長か弱いハッシュアルゴリズムが西暦に関するユーティリティを制限するでしょう。 AAsが強い暗号のテクニックを使うことができるように暗号理論における進歩に注意するよう奨励されます。
If an AC is tied to the holder's PKC using the baseCertificateID component of the Holder field and the PKI in use includes a rogue CA with the same issuer name specified in the baseCertificateID component, this rogue CA could issue a PKC to a malicious party, using the same issuer name and serial number as the proper holder's PKC. Then the malicious party could use this PKC in conjunction with the AC. This scenario SHOULD be avoided by properly managing and configuring the PKI so that there cannot be two CAs with the same name. Another alternative is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. Failing this, AC verifiers have to establish (using other means) that the potential collisions cannot actually occur; for example, the Certificate Policy Statements (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)がかかわったCertificate Policy Statementsは、どんなそのような名前衝突も起こることができないと断言するかもしれません。
Francis & Pinkas Standards Track [Page 6] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[6ページ]。
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. AC verifiers SHALL support means of being provided with this information. The AA controls PKC extension (see [RFC3281]) is one possibility, but it is optional to implement. Configuration information is a likely alternative means, while out-of-band means is another. This becomes very important if an AC verification application trusts more than one AC issuer.
Implementersは、西暦の合法化に続いて、発行人が発行すると信じられる属性だけが承認決定に使用されるのを確実にしなければなりません。 他の属性(存在しているかもしれない)を無視しなければなりません。 交流検証SHALLはこの情報を提供する手段をサポートします。 AAコントロールPKC拡張子([RFC3281]を見る)は1つの可能性ですが、それは、実装するために任意です。 設定情報はありそうな代替の手段ですが、バンドの外では、手段は別です。 交流検証アプリケーションが1つ以上の交流発行人を信じるなら、これは非常に重要になります。
4. IANA Considerations
4. IANA問題
The AC policies extension is identified by an object identifier (OID). The OID for the AC policies extension defined in this document was assigned from an arc delegated by the IANA to the PKIX Working Group.
オブジェクト識別子(OID)によって交流方針拡大は特定されます。 本書では定義された交流方針拡大のためのOIDはIANAによって代表として派遣されたアークからPKIX作業部会まで割り当てられました。
No further action by the IANA is necessary for this document.
IANAによるさらなるどんな動作もこのドキュメントに必要ではありません。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[X.660|ISO9834-1] ITU-T Recommendation X.660 (1992) | ISO/IEC 9834-1:
1993, Information technology - Open Systems
Interconnection Procedures for the operation of OSI
Registration Authorities: General procedures.
[X.660| ISO9834-1] ITU-T推薦X.660(1992)| ISO/IEC9834-1: 1993、情報技術--OSI Registration Authoritiesの操作のためのオープン・システム・インターコネクションProcedures: 基本手順。
[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月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281,
April 2002.
[RFC3281]ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax
Notation One (ASN.1).
[ASN1]X.680--X.693| ISO/IEC8824: 1-4 抽象構文記法1(ASN.1)。
Francis & Pinkas Standards Track [Page 7] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[7ページ]。
5.2. Informative Reference
5.2. 有益な参照
[X.509] ITU-T Recommendation X.509 (2000): Information
Technology Open Systems Interconnections - The
Directory: Public-key and Attribute Frameworks,
March 2000.
[X.509]ITU-T推薦X.509(2000): 情報技術開放型システム間相互接続--ディレクトリ: 公開鍵と属性フレームワーク、2000年3月。
Francis & Pinkas Standards Track [Page 8] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[8ページ]。
Appendix A. ASN.1 Definitions
付録A.ASN.1定義
This appendix is normative.
この付録は規範的です。
ASN.1 Module
ASN.1モジュール
AcPolicies { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ac-policies(26) }
AcPoliciesiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ-ac方針(26)
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてをエクスポートします--
IMPORTS
輸入
-- Imports from RFC 3280 [RFC3280], Appendix A
-- RFC3280[RFC3280]、付録Aからの輸入
UserNotice
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) 19 }
PKIX1Implicit88からのUserNoticeiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)19
id-pkix, id-pe
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) 18 };
イド-pkix、イド-pe FROM PKIX1Explicit88iso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)18。
-- Locally defined OIDs
-- 局所的に定義されたOIDs
-- policyQualifierIds for Internet policy qualifiers
-- インターネット方針資格を与える人のためのpolicyQualifierIds
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 }
id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 }
イド-qt OBJECT IDENTIFIER:、:= イド-pkix2、イド-qt-acps OBJECT IDENTIFIER:、:= イド-qt4、イド-qt-acunotice OBJECT IDENTIFIER:、:= イド-qt5
-- Attributes
-- 属性
id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 }
イド-pe-acPoliciesオブジェクト識別子:、:= イド-pe15
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
AcPoliciesSyntax:、:= PolicyInformationの系列サイズ(1..MAX)
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
PolicyInformation:、:= 系列policyIdentifier AcPolicyId、PolicyQualifierInfo任意のpolicyQualifiers系列サイズ(1..MAX)
Francis & Pinkas Standards Track [Page 9] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[9ページ]。
AcPolicyId ::= OBJECT IDENTIFIER
AcPolicyId:、:= オブジェクト識別子
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierInfo:、:= 系列policyQualifierId PolicyQualifierId、資格を与える人いずれもDEFINED BY policyQualifierId
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
-- ACPS pointer qualifier
PolicyQualifierId:、:= OBJECT IDENTIFIER(イド-qt-acps| イド-qt-acunotice)--ACPS指針資格を与える人
ACPSuri ::= IA5String -- ACP statement user notice qualifier
ACPSuri:、:= IA5String--ACP声明ユーザ通知資格を与える人
ACUserNotice ::= UserNotice -- UserNotice is defined in [RFC3280]
ACUserNotice:、:= UserNotice--UserNoticeは中で定義されます。[RFC3280]
END
終わり
Authors' Addresses
作者のアドレス
Christopher S. Francis Raytheon 1501 72nd Street North, MS 25 St. Petersburg, Florida 33764
クリストファーS.フランシスレイセオン1501第72通りの北部、サンクトペテルブルグ、MS25フロリダ 33764
EMail: Chris_S_Francis@Raytheon.com
メール: Chris_S_Francis@Raytheon.com
Denis Pinkas Bull Rue Jean Jaures 78340 Les Clayes-sous-Bois FRANCE
デニス・ピンカス・雄牛悔悟ジーン・ジョーレス78340・レス・Clayes小銭Boisフランス
EMail: Denis.Pinkas@bull.net
メール: Denis.Pinkas@bull.net
Francis & Pinkas Standards Track [Page 10] RFC 4476 AC Policies Extension May 2006
フランシスとピンカスStandardsは交流方針拡大2006年5月にRFC4476を追跡します[10ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Francis & Pinkas Standards Track [Page 11]
フランシスとピンカス標準化過程[11ページ]
一覧
スポンサーリンク
