[要約] RFC 4476は、Attribute Certificate (AC) Policies Extensionに関する仕様であり、ACのポリシーを拡張するための方法を提供しています。目的は、ACのポリシーを明確に定義し、信頼性とセキュリティを向上させることです。
Network Working Group C. Francis
Request for Comments: 4476 Raytheon
Category: Standards Track D. Pinkas
Bull
May 2006
Attribute Certificate (AC) Policies Extension
属性証明書（AC）ポリシー拡張
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).
Copyright（c）The Internet Society（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）を明示的に述べる1つの証明書拡張機能について説明します。このドキュメントの目標は、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）は、被験者のIDに関してさまざまなレベルの検証を実行できます（[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
定義は、1997年の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ポリシーの識別に使用されるオブジェクト識別子は、[x.660 | ISO9834-1]に従って割り当てられます。
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.
この拡張機能とそのコンテンツを認識するアプリケーションは、臨界フラグの値に関係なく拡張機能を処理するものとします。
If the extension is both flagged non-critical and not recognized by the AC-using application, then the application MAY ignore it.
拡張機能の両方が非批判的であり、AC使用アプリケーションによって認識されていない場合、アプリケーションはそれを無視する場合があります。
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
- インターネットポリシー予選のためのPolicyQualifierid
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）のみで構成されることを推奨しています。複数のポリシーが使用される場合、ポリシーの要件は非紛争でなければなりません。たとえば、あるポリシーは、別のポリシーによって義務付けられている一般的な要件を改良する場合があります。
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ライターとAASが使用する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ユーザー通知を表示する必要があります。ACユーザー通知は[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フィールドは、使用すると組織に名前を付け、その組織が作成した特定のテキストステートメントを数字で識別します。たとえば、組織の名前と通知番号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.
このドキュメントの範囲は、ACPS自体の詳細な内容の定義ではありません。したがって、このドキュメントでは特定のポリシーが定義されていません。
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に含まれるすべての属性に適用されます。AASは、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で動的にグループ化できます。ACは複数のACPの下で発行される可能性があるため、特定のACに含まれる属性は、そのACのすべてのACPに準拠する必要があることが観察される必要があります。
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.
AASがプライベートキーを保護できなかった場合、攻撃者が攻撃者を装って、誤ったACSまたは取消ステータスを生成する可能性があります。偽の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.
このような妥協の後の再建には問題があるため、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は取り消しステータスを作成したり、AC更新を実行したりすることはできません（つまり、同じホルダーに対して、同じ値の同じ値を持つ同じ属性セットを持つ新しいACの問題は、同じAAから異なる妥当性期間を持つ問題）を実行することはできません。。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に配置されるべき保証の程度に影響します。長寿命のACは自然に期限切れになりますが、ACホルダーと属性の間の結合を無効にするACの自然な寿命の間にイベントが発生する可能性があります。失効ステータスが早すぎる場合、または利用できない場合、バインディングに関連する保証は明らかに減少します。
The binding between an AC holder and attributes cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of an AC. AAs are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
ACホルダーと属性の間のバインディングは、署名を生成するために使用される暗号化モジュールの実装とアルゴリズムよりも強くなることはできません。キーの長さが短いまたは弱いハッシュアルゴリズムは、ACのユーティリティを制限します。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.
ACがホルダーフィールドのベースコンチェクテートコンポーネントと使用中のPKIを使用してホルダーのPKCに結び付けられている場合、ベースティーティフィケイトコンポーネントで指定された同じ発行者名を持つ不正なCAが含まれている場合、この不正なCAは、悪意のあるパーティーにPKCを発行する可能性があります。適切な所有者のPKCと同じ発行者名とシリアル番号。その後、悪意のあるパーティーは、このPKCをACと併用することができます。このシナリオは、PKIを適切に管理および構成して、同じ名前の2つのCAが存在できないように回避する必要があります。もう1つの選択肢は、ObjectDigestInfoフィールドのPublicKeyCertタイプを使用してACSをPKCに結び付けることです。これに失敗すると、AC検証は（他の手段を使用して）潜在的な衝突が実際に発生しないことを確立する必要があります。たとえば、関係するCAの証明書ポリシー声明（CPS）は、そのような名前の衝突が発生しないことを明らかにする可能性があります。
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present, MUST be ignored. 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は、IANAからPKIXワーキンググループに委任されたアークから割り当てられました。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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] Farrell、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月。
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) }
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 }
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 };
-- Locally defined OIDs
- ローカルで定義されたOID
-- policyQualifierIds for Internet policy qualifiers
- インターネットポリシー予選のためのPolicyQualifierid
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 72nd Street North、MS 25 St. Petersburg、Florida 33764
EMail: Chris_S_Francis@Raytheon.com
Denis Pinkas Bull Rue Jean Jaures 78340 Les Clayes-sous-Bois FRANCE
デニス・ピンカス・ブル・ルー・ジャン・ジュール78340レス・クレイズ・サウス・ボア・フランス
EMail: Denis.Pinkas@bull.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。