Network Working Group C. Francis
Request for Comments: 4476 Raytheon
Category: Standards Track D. Pinkas
Bull
May 2006
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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.
この文書は、明示的に指定した属性証明書（AC）に適用される属性証明書ポリシー（ACPを）述べつの証明書の拡張機能について説明します。この文書の目的は、いくつかの属性を保有する所定のACは、1つ以上の特定のACPへの参照に基づいて受け入れられるかどうかを評価するために、即ち、ACを検証するときに、追加のテストを実行する依拠当事者可能にすることです。
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.
公開鍵証明書（PKC）を発行すると、認証局（CA）は、対象のアイデンティティに関して検証のさまざまなレベルを行うことができます（[RFC3280]を参照）。 CAは、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].
このドキュメントの目的は、明示的に与えられたACに適用するACポリシーを述べることができる属性証明書（AC）ポリシー拡張を定義することではなく、AC政策そのもの。属性証明書は、[RFC3281]で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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.
属性証明書ポリシーは、特定のコミュニティおよび/または共通のセキュリティ要件を持つアプリケーションのクラスにACの適用可能性を示したルールの名前付きセットです。それは、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.
このように、属性認証局（AA）は、必ずしも1つのACPをサポートしていないことに注意してください。しかし、配信された各ACのために、AAは、ポリシーがそれに含まれているすべての属性に適用されていることを確認しなければなりません。
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は、特定の目的のためにACに含まれる属性を信頼するかどうかを決定するためにACのユーザによって使用されてもよいです。
When an AC contains an AC policies extension, the extension MAY, at the option of the AA, be either critical or non-critical.
ACはACポリシーの拡張機能が含まれている場合は、拡張子は、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.
ACポリシー拡張は、ACに含まれるかもしれません。すべてのX.509証明書拡張[X.509]と同様に、ACポリシー機能拡張は、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.
定義は、むしろ最新のISO / IEC / ITU-T規格で使用される1997 ASN.1構文よりも1988抽象構文記法1（ASN.1）に提示されています。
The AC policies extension is identified by id-pe-acPolicies.
ACポリシーの拡張機能は、ID-PE-acPoliciesによって識別されます。
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 }
The AC policies extension includes a list of AC policies recognized by the AA that apply to the attributes included in the AC.
ACポリシー拡張は、ACに含ま属性に適用AAによって認識ACポリシーのリストが含まれています。
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].
ACポリシーは、必要とどのような組織によって定義することができます。 ACポリシーを識別するために使用されるオブジェクト識別子は、[| ISO9834-1 X.660]に従って割り当てられます。
The AC policies extension in an AC indicates the AC policies for which the AC is valid.
ACでのACポリシー拡張は、ACが有効であるAC方針を示しています。
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.
拡張機能の両方が重要でないとAC-使用して、アプリケーションで認識されないフラグが立てられている場合、アプリケーションはそれを無視してもよい（MAY）。
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.
拡張子が重要なマークされているか、AC-使用して、アプリケーションによって認識されている場合は、属性証明書に含まれている属性は、目的のためにのみ使用されなければならないことを示している、と示されているAC政策の一つに関連付けられたルールに従ってインチACP識別子のいずれもアプリケーションに適していない場合は、ACを拒絶しなければなりません。
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によって認識されている場合は、AC-使用するアプリケーションは、特定の取引のためにそのACに含まれる属性を使用することが適切であるかどうかを判断するためにACポリシーのリストを使用しなければなりません。適切なポリシーが見つからない場合は、ACは拒否されるものとします。
The syntax for the AC Policy extension is:
ACポリシー拡張のための構文は次のとおりです。
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL}
AcPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY 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 }
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 }
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 }
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
-- ACPS pointer qualifier
- ACPSポインタ修飾子
ACPSuri ::= IA5String
-- ACP statement user notice qualifier
ACUserNotice ::= UserNotice
-- UserNotice is defined in [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.
相互運用性を促進するには、この文書には、ポリシー情報項目は唯一のオブジェクト識別子（OID）からなることをお勧めします。複数のポリシーを使用する場合、ポリシー要件は、非競合しなければならず、例えば、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.
この仕様で定義された拡張は、ACPの作家とのAAで使用するための2つのポリシー修飾子タイプをサポートしています。修飾子のタイプはACPSポインタとACユーザーです。
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ポインタ修飾子は、AAによって公開属性認証実施規定（ACPS）へのポインタが含まれています。ポインタは、URIの形態です。この修飾子の処理要件は、ローカルの問題です。
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.
属性証明書が使用されているときは、ACユーザ通知は、証明書利用者に表示するためのものです。アプリケーション・ソフトウェアは、ACの交流ユーザ通知が表示されます。 ACユーザ通知は[RFC3280]で定義されています。 noticeRefフィールドとexplicitTextのフィールド：これは2つのオプションのフィールドがあります。
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フィールド、使用している場合、名前の組織と識別し、。例えば、それは典型的な実装では、組織の名前と通告番号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オプションで指定された通知テキストを見つけることができれば、と、そのテキストが表示されるはずです。それ以外の場合は、explicitTextの文字列が表示されるはずです。
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.
この文書の範囲は、ACPの自身の詳細な内容の定義ではありません。そのため、具体的な政策は、この文書で定義されていません。
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つのACに含まれているすべての属性に適用されます。 AAは、ACPは、彼らが出すのACに含まれているすべての属性に適用されることを保証しなければなりません。
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でグループ化することができます。そのACからのすべてのACPに準拠している必要がありACは、複数のACPの下で発行される可能性があるため、属性が与えられたACに含まれていることが観察されなければなりません。
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.
ACを検証する際に、証明書利用者は、ACが信頼AAによって発行され、それが適切なポリシーを持っていることをしていることを決定しなければなりません。
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.
自分の秘密鍵を保護するためのAAの失敗は、潜在的に虚偽のACまたは失効状態を生成し、それらを装うために、攻撃者が許可されます。偽のACSおよび失効状態の存在は、システムへの信頼を損なうだろう。妥協が検出された場合、AAの証明書が取り消されなければなりません。
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.
AAと強い技術的手段（例えば、耐タンパー暗号モジュール）及び適切な管理手順の組み合わせを実装することをお勧めしますので、そのような妥協した後に再構築することは、問題となるであろう（例えば、職務の分離）は、このような事故を回避します。
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は（すなわち、同じ値を持つ属性の同じセットを使って、新しいACの問題、同じホルダーのために、同じAAからではなく、異なる有効期間で）失効状態を作り出すか、ACの更新を実行することはできません。 ACの発行者は、署名鍵のための安全なバックアップを維持することをお勧めします。キーのバックアップ手順のセキュリティは鍵の危殆化を回避する上で重要な要因です。
The availability and freshness of revocation status will affect the degree of assurance that should be placed in a long-lived AC. While long-lived ACs expire naturally, events may occur during 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.
失効状態の可用性と新鮮さは、長寿命のACに置く必要があります保証の度合いに影響を与えます。長寿命ACSは自然に期限が切れるが、イベントはACホルダーと属性の間の結合を否定ACの自然の存続期間中に発生する可能性があります。失効状態が早すぎるか使用できない場合、結合に関連した保証が明らかに減少しています。
The binding between an AC holder and attributes cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of an AC. AAs are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
ACホルダーと属性との間の結合は、署名を生成するために使用される暗号モジュールの実装とアルゴリズムよりも強いことができません。短い鍵長または弱いハッシュアルゴリズムはACの有用性を制限します。 AAは、彼らは強力な暗号技術を採用することができますので、暗号技術の進歩に留意することが奨励されています。
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.
ACは、ホルダーフィールドのbaseCertificateIDコンポーネントを使用して、保有者のPKCに結びついていると、使用中のPKIはbaseCertificateIDコンポーネントに指定したのと同じ発行者名の不正なCAを含み、この不正CAは使用して、悪質なパーティにPKCを発行することができれば同じ発行者名と適切な保有者のPKCとしてのシリアル番号。その後、悪意のあるパーティはACと一緒にこのPKCを使用することができます。このシナリオでは、適切に管理し、同じ名前の2つのCAは存在しないことができるようにPKIを構成することによって避けるべきです。別の代替は、ObjectDigestInfoフィールドにpublicKeyCertタイプを使用してのPKCにACSを結びつけることです。この失敗は、AC検証者は、潜在的な衝突が実際に発生することができないこと（他の手段を使用して）を確立しなければなりません。例えば、関連するCAの証明書ポリシーステートメント（CPSS）は、そのような名前の衝突が発生しないことを、それを明確にすることがあります。
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present, MUST be ignored. 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.
実装者は、ACの検証以下、唯一の発行者が問題に信頼されていることの属性が、認可の決定に使用されていることを確認しなければなりません。存在し得る他の属性は、無視しなければなりません。 ACの検証は、この情報が提供されているの手段をサポートします。 AAは、PKCの拡張を制御する（[RFC3281]を参照）1つの可能性であるが、実装するために任意です。アウト・オブ・バンドが別であることを意味しながら、構成情報は、可能性の高い代替手段です。 ACの検証アプリケーションが複数のAC発行者を信頼している場合、これは非常に重要になります。
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.
ACポリシー拡張は、オブジェクト識別子（OID）によって識別されます。この文書で定義されたACポリシー機能拡張のためのOIDは、PKIXワーキンググループにIANAによって委任アークから割り当てられました。
No further action by the IANA is necessary for this document.
IANAによってそれ以上のアクションは、この文書のために必要ありません。
[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 / IEC 9834から1：1993、情報技術 - OSI登録機関の運転のための開放型システム間相互接続手順：一般的な手順。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[RFC3281]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
[ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax Notation One (ASN.1).
[ASN1] X.680 - X.693 | ISO / IEC 8824：1-4抽象構文記法1（ASN.1）。
[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月。
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) }
AcPolicies {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-AC-ポリシー（26）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
-- Imports from RFC 3280 [RFC3280], Appendix A
- RFC 3280 [RFC3280]、付録Aからの輸入
UserNotice
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(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 };
ID-PKIX、PKIX1Explicit88からID-PE {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）18}。
-- Locally defined OIDs
- ローカルに定義されたOID
-- 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 }
-- Attributes
- 属性
id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 }
AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier AcPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
AcPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
-- ACPS pointer qualifier
ACPSuri ::= IA5String
-- ACP statement user notice qualifier
ACUserNotice ::= UserNotice
-- UserNotice is defined in [RFC3280]
END
終わり
Authors' Addresses
著者のアドレス
Christopher S. Francis Raytheon 1501 72nd Street North, MS 25 St. Petersburg, Florida 33764
クリストファーS.フランシスレイセオン1501第72回ストリート北、MS 25セント・ピーターズバーグ、フロリダ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-スーボワFRANCE
EMail: Denis.Pinkas@bull.net
メールアドレス：Denis.Pinkas@bull.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。