RFC2587 日本語訳

Network Working Group                                     S. Boeyen
Request for Comments: 2587                                  Entrust
Category: Standards Track                                  T. Howes
                                                           Netscape
                                                         P. Richard
                                                              Xcert
                                                          June 1999

Boeyenがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2587はカテゴリをゆだねます: 標準化過程T.ハウズNetscape P.リチャードXcert1999年6月

                Internet X.509 Public Key Infrastructure
                             LDAPv2 Schema

インターネットX.509公開鍵暗号基盤LDAPv2図式

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 (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

1.  Abstract

1. 要約

   The schema defined in this document is a minimal schema to support
   PKIX in an LDAPv2 environment, as defined in RFC 2559.  Only PKIX-
   specific components are specified here.  LDAP servers, acting as PKIX
   repositories should support the auxiliary object classes defined in
   this specification and integrate this schema specification with the
   generic and other application-specific schemas as appropriate,
   depending on the services to be supplied by that server.

本書では定義された図式はLDAPv2環境でPKIXをサポートする最小量の図式です、RFC2559で定義されるように。 PKIXの特定の部品だけがここで指定されます。 LDAPサーバ、ジェネリックと他のアプリケーション特有のschemasが適切な状態で、PKIX倉庫として機能するのは、補助のオブジェクトがこの仕様に基づき定義されたクラスであるとサポートして、この図式仕様を統合するべきです、そのサーバによって供給されるサービスによって。

   The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
   and 'MAY' in this document are to be interpreted as described in RFC
   2119.

キーワード'MUST'、'SHALL'、'REQUIRED'、'SHOULD'、'RECOMMENDED'、およびこのドキュメントの'5月'はRFC2119で説明されるように解釈されることになっています。

2.  Introduction

2. 序論

   This specification is part of a multi-part standard for development
   of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
   mechanism defined for access to a PKI repository. Other mechanisms,
   such as http, are also defined. If an LDAP server, accessed by LDAPv2
   is used to provide a repository, the minimum requirement is that the
   repository support the addition of X.509 certificates to directory

この仕様はインターネットへの公開鍵暗号基盤(PKI)の開発の複合規格の一部です。 LDAPv2はPKI倉庫へのアクセスのために定義された1つのメカニズムです。 また、httpなどの他のメカニズムは定義されます。 LDAPv2によってアクセスされたLDAPサーバがそうであるなら、倉庫、必要最小限を提供するのにおいて使用されているのは、倉庫がX.509証明書の追加をディレクトリにサポートするということです。

Boeyen, et al.              Standards Track                     [Page 1]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[1ページ]。

   entries.  Certificate Revocation List (CRL)is one mechanism for
   publishing revocation information in a repository.  Other mechanisms,
   such as http, are also defined.

エントリー。 証明書Revocation List(CRL)は、倉庫で取消し情報を発表するための1つのメカニズムです。 また、httpなどの他のメカニズムは定義されます。

   This specification defines the attributes and object classes to be
   used by LDAP servers acting as PKIX repositories and to be understood
   by LDAP clients communicating with such repositories to query, add,
   modify and delete PKI information. Some object classes and attributes
   defined in X.509 are duplicated here for completeness. For end
   entities and Certification Authorities (CA), the earlier X.509
   defined object classes mandated inclusion of attributes which are
   optional for PKIX. Also, because of the mandatory attribute
   specification, this would have required dynamic modification of the
   object class attribute should the attributes not always be present in
   entries. For these reasons, alternative object classes are defined in
   this document for use by LDAP servers acting as PKIX repositories.

この仕様は、PKI情報を質問して、加えて、変更して、削除するためにそのような倉庫で交信するLDAPクライアントにPKIX倉庫として機能するLDAPサーバによって使用されて、解釈されるために属性とオブジェクトのクラスを定義します。 X.509で定義されたいくつかのオブジェクトのクラスと属性が完全性のためにここにコピーされます。 終わりの実体とCertification Authorities(カリフォルニア)に関しては、定義されたオブジェクトが分類する以前のX.509はPKIXに、任意の属性の包含を強制しました。 また、義務的な属性仕様のために、属性がエントリーにいつも存在しているというわけではないなら、これはオブジェクトクラス属性のダイナミックな変更を必要としたでしょう。 これらの理由で、代替のオブジェクトのクラスは本書では使用のためにPKIX倉庫として機能するLDAPサーバによって定義されます。

3.  PKIX Repository Objects

3. PKIX倉庫オブジェクト

   The primary PKIX objects to be represented in a repository are:

倉庫に表されるべきプライマリPKIXオブジェクトは以下の通りです。

      -  End Entities
      -  Certification Authorities (CA)

- 終わりの実体--証明当局(カリフォルニア)

   These objects are defined in RFC 2459.

これらのオブジェクトはRFC2459で定義されます。

3.1.  End Entities

3.1. 終わりの実体

   For purposes of PKIX schema definition, the role of end entities as
   subjects of certificates is the major aspect relevant to this
   specification. End entities may be human users, or other types of
   entities to which certificates may be issued. In some cases, the
   entry for the end entity may already exist and the PKI-specific
   information is added to the existing entry. In other cases the entry
   may not exist prior to the issuance of a certificate, in which case
   the entity adding the certificate may also need to create the entry.
   Schema elements used to represent the non PKIX aspects of an entry,
   such as the structural object class used to represent organizational
   persons, may vary, depending on the particular environment and set of
   applications served and are outside the scope of this specification.

PKIX図式定義の目的のために、証明書の対象としての終わりの実体の役割はこの仕様に関連している主要な局面です。 終わりの実体は証明書が発行されるかもしれない人間のユーザ、または他のタイプの実体であるかもしれません。 いくつかの場合、終わりの実体のためのエントリーは既に存在するかもしれません、そして、PKI-特殊情報は既存のエントリーに加えられます。 他の場合では、エントリーは証明書の発行の前に存在しないかもしれません、その場合、また、証明書を加える実体がエントリーを作成する必要があるかもしれません。 図式要素は、以前はよく組織的な人々の代理をするのに使用される構造的なオブジェクトのクラスなどのエントリーの非PKIX局面を表していて、役立たれるアプリケーションの特定の環境とセットによって、異なるかもしれなくて、この仕様の範囲の外にあります。

   The following auxiliary object class MAY be used to represent
   certificate subjects:

以下の補助のオブジェクトのクラスは証明書対象を表すのに使用されるかもしれません:

Boeyen, et al.              Standards Track                     [Page 2]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[2ページ]。

pkiUser   OBJECT-CLASS   ::= {
   SUBCLASS OF   { top}
   KIND          auxiliary
   MAY CONTAIN   {userCertificate}
   ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}

pkiUserは以下をオブジェクトで分類します:= SUBCLASS OFがKINDの補助のMAY CONTAIN userCertificateを上回っている、IDの共同iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)

userCertificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   Certificate
     EQUALITY MATCHING RULE   certificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }

userCertificateは以下を結果と考えます:= WITH SYNTAX Certificate EQUALITY MATCHING RULE certificateExactMatchのIDの共同iso-ccitt(2) ds(5) attributeType(4) userCertificate(36)

   An end entity may obtain one or more certificates from one or more
   Certification Authorities.  The userCertificate attribute MUST be
   used to represent these certificates in the directory entry
   representing that user.

終わりの実体は1Certification Authoritiesから1通以上の証明書を入手するかもしれません。 そのユーザの代理をしながらディレクトリエントリにこれらの証明書を表すのにuserCertificate属性を使用しなければなりません。

3.2.  Certification Authorities

3.2. 証明当局

   As with end entities, Certification Authorities are typically
   represented in directories as auxiliary components of entries
   representing a more generic object, such as organizations,
   organizational units etc. The non PKIX-specific schema elements for
   these entries, such as the structural object class of the object, are
   outside the scope of this specification.

Certification Authoritiesが終わりの実体のように表しながらエントリーの補助のコンポーネントとしてディレクトリに通常表される、 より多くのジェネリックオブジェクト、ユニットの組織的な組織など この仕様の範囲の外にオブジェクトの構造的なオブジェクトのクラスなどのこれらのエントリーへの非PKIXに特定の図式要素があります。

   The following auxiliary object class MAY be used to represent
   Certification Authorities:

以下の補助のオブジェクトのクラスはCertification Authoritiesを表すのに使用されるかもしれません:

pkiCA   OBJECT-CLASS   ::= {
   SUBCLASS OF   { top}
   KIND          auxiliary
   MAY CONTAIN   {cACertificate |
                  certificateRevocationList |
                  authorityRevocationList |
                  crossCertificatePair }
   ID    joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}

pkiCAは以下をオブジェクトで分類します:= SUBCLASS OFがKINDの補助のMAY CONTAINを上回っている、cACertificate|certificateRevocationList|authorityRevocationList| crossCertificatePair、IDの共同iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)

cACertificate    ATTRIBUTE  ::=  {
     WITH SYNTAX   Certificate
     EQUALITY MATCHING RULE   certificateExactMatch
     ID  joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }

cACertificateは以下を結果と考えます:= WITH SYNTAX Certificate EQUALITY MATCHING RULE certificateExactMatchのIDの共同iso-ccitt(2) ds(5) attributeType(4) cACertificate(37)

crossCertificatePairATTRIBUTE::={
   WITH SYNTAX   CertificatePair
   EQUALITY MATCHING RULE certificatePairExactMatch
 ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}

crossCertificatePairATTRIBUTE:、:=WITH SYNTAX CertificatePairのEQUALITY MATCHING RULE certificatePairExactMatchのIDの共同iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)

Boeyen, et al.              Standards Track                     [Page 3]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[3ページ]。

   The cACertificate attribute of a CA's directory entry shall be used
   to store self-issued certificates (if any) and certificates issued to
   this CA by CAs in the same realm as this CA.

CAのディレクトリエントリのcACertificate属性は、(もしあれば)の自己によって発行された証明書とこのカリフォルニアと同じ分野でCAsによってこのカリフォルニアに発行された証明書を保存するのに使用されるものとします。

   The forward elements of the crossCertificatePair attribute of a CA's
   directory entry shall be used to store all, except self-issued
   certificates issued to this CA.  Optionally, the reverse elements of
   the crossCertificatePair attribute, of a CA's directory entry may
   contain a subset of certificates issued by this CA to other CAs.
   When both the forward and the reverse elements are present in a
   single attribute value, issuer name in one certificate shall match
   the subject name in the other and vice versa, and the subject public
   key in one certificate shall be capable of verifying the digital
   signature on the other certificate and vice versa.

CAのディレクトリエントリのcrossCertificatePair属性の急進的な要素はすべてを保存するのに使用されるものとします、このカリフォルニアに発行された自己によって発行された証明書を除いて。 任意に、crossCertificatePair属性、CAのディレクトリエントリの逆要素は含むかもしれません。このカリフォルニアによって他のCAsに発行された証明書の部分集合を含んでください。 フォワードと逆の要素の両方がただ一つの属性値で存在しているとき、1通の証明書の発行人名は逆もまた同様にもう片方における対象の名前に合っているものとします、そして、1通の証明書の対象の公開鍵はもう片方の証明書の上に逆もまた同様にデジタル署名について確かめることができるでしょう。

   When a reverse element is present, the forward element value and the
   reverse element value need not be stored in the same attribute value;
   in other words, they can be stored in either a single attribute value
   or two attribute values.

逆の要素が存在しているとき、前進の要素値と逆の要素値は同じ属性値で保存される必要はありません。 言い換えれば、ただ一つの属性値か2つの属性値のどちらかでそれらを保存できます。

   In the case of V3 certificates, none of the above CA certificates
   shall include a basicConstraints extension with the cA value set to
   FALSE.

V3証明書の場合では、上記のカリフォルニア証明書のいずれもcA選択値群によるbasicConstraints拡張子をFALSEに含んでいないものとします。

   The definition of realm is purely a matter of local policy.

分野の定義は純粋にローカルの方針の問題です。

      certificateRevocationListATTRIBUTE::={
           WITH SYNTAX  CertificateList
           EQUALITY MATCHING RULE certificateListExactMatch
        ID joint-iso-ccitt(2) ds(5) attributeType(4)
           certificateRevocationList(39)}

certificateRevocationListATTRIBUTE:、:=WITH SYNTAX CertificateListのEQUALITY MATCHING RULE certificateListExactMatchのIDの共同iso-ccitt(2) ds(5) attributeType(4) certificateRevocationList(39)

   The certificateRevocationList attribute, if present in a particular
   CA's entry, contains CRL(s) as defined in RFC 2459.

特定のCAのエントリーに存在しているなら、certificateRevocationList属性はRFC2459で定義されるようにCRL(s)を含んでいます。

      authorityRevocationListATTRIBUTE::={
         WITH SYNTAX   CertificateList
         EQUALITY MATCHING RULE certificateListExactMatch
       ID joint-iso-ccitt(2) ds(5) attributeType(4)
          authorityRevocationList(38)}

authorityRevocationListATTRIBUTE:、:=WITH SYNTAX CertificateListのEQUALITY MATCHING RULE certificateListExactMatchのIDの共同iso-ccitt(2) ds(5) attributeType(4) authorityRevocationList(38)

   The authorityRevocationList attribute, if present in a particular
   CA's entry, includes revocation information regarding certificates
   issued to other CAs.

特定のCAのエントリーに存在しているなら、authorityRevocationList属性は他のCAsに発行された証明書の取消し情報を含んでいます。

Boeyen, et al.              Standards Track                     [Page 4]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[4ページ]。

3.2.1.  CRL distribution points

3.2.1. CRL分配ポイント

   CRL distribution points are an optional mechanism, specified in RFC
   2459, which MAY be used to distribute revocation information.

CRL分配ポイントは取消し情報を分配するのに使用されるかもしれないRFC2459で指定された任意のメカニズムです。

   A patent statement regarding CRL distribution points can be found at
   the end of this document.

このドキュメントの端でCRL分配ポイントに関する特許声明を見つけることができます。

   If a CA elects to use CRL distribution points, the following object
   class is used to represent these.

カリフォルニアが、CRL分配ポイントを使用するのを選ぶなら、以下のオブジェクトのクラスは、これらを表すのに使用されます。

 cRLDistributionPoint   OBJECT-CLASS::= {
    SUBCLASS OF     { top }
    KIND            structural
    MUST CONTAIN    { commonName }
    MAY CONTAIN     { certificateRevocationList |
                      authorityRevocationList |
                      deltaRevocationList }
    ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }

cRLDistributionPointは以下をオブジェクトで分類します:= SUBCLASS OFがKINDの構造的なMUST CONTAIN commonNameを上回っている、MAY CONTAIN certificateRevocationList|authorityRevocationList|deltaRevocationList、IDの共同iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19)

   The certificateRevocationList and authorityRevocationList attributes
   are as defined above.

上で定義されるとしてcertificateRevocationListとauthorityRevocationList属性があります。

   The commonName attribute and deltaRevocationList attributes, defined
   in X.509, are duplicated below.

X.509で定義されたcommonName属性とdeltaRevocationList属性は以下にコピーされます。

      commonName   ATTRIBUTE::={
         SUBTYPE OF     name
         WITH SYNTAX   DirectoryString
         ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }

commonNameは以下を結果と考えます:=SUBTYPE OF名前WITH SYNTAX DirectoryString IDジョイント-iso-ccitt(2) ds(5) attributeType(4) commonName(3)

      deltaRevocationList        ATTRIBUTE ::= {
         WITH SYNTAX             CertificateList
         EQUALITY MATCHING RULE  certificateListExactMatch
         ID joint-iso-ccitt(2) ds(5) attributeType(4)
            deltaRevocationList(53) }

deltaRevocationListは以下を結果と考えます:= WITH SYNTAX CertificateListのEQUALITY MATCHING RULE certificateListExactMatchのIDの共同iso-ccitt(2) ds(5) attributeType(4) deltaRevocationList(53)

3.2.2.  Delta CRLs

3.2.2. デルタCRLs

   Delta CRLs are an optional mechanism, specified in RFC 2459, which
   MAY be used to enhance the distribution of revocation information.

デルタCRLsは取消し情報の分配を機能アップするのに使用されるかもしれないRFC2459で指定された任意のメカニズムです。

   If a CA elects to use delta CRLs, the following object class is used
   to represent these.

カリフォルニアが、デルタCRLsを使用するのを選ぶなら、以下のオブジェクトのクラスは、これらを表すのに使用されます。

Boeyen, et al.              Standards Track                     [Page 5]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[5ページ]。

      deltaCRL   OBJECT-CLASS::= {
         SUBCLASS OF     { top }
         KIND            auxiliary
         MAY CONTAIN     { deltaRevocationList }
         ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }

deltaCRLは以下をオブジェクトで分類します:= SUBCLASS OFがKINDの補助のMAY CONTAIN deltaRevocationListを上回っている、IDの共同iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23)

4.  Security Considerations

4. セキュリティ問題

   Since the elements of information which are key to the PKI service
   (certificates and CRLs) are both digitally signed pieces of
   information, no additional integrity service is REQUIRED.

情報のPKIサービス(証明書とCRLs)に主要な要素が情報の断片であるとデジタルにともに署名されるので、どんな追加保全サービスもREQUIREDではありません。

   Security considerations with respect to retrieval, addition,
   deletion, and modification of the information supported by this
   schema definition are addressed in RFC 2559.

この図式定義でサポートされた情報の検索に関するセキュリティ問題、追加、削除、および変更はRFC2559で扱われます。

5.  References

5. 参照

   [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol", RFC 1777, March 1995.

[1]YeongとY.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。

   [2]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、1997年3月。

6  Intellectual Property Rights

6 知的所有権

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

Boeyen, et al.              Standards Track                     [Page 6]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[6ページ]。

7.  Authors' Addresses

7. 作者のアドレス

   Sharon Boeyen
   Entrust Technologies Limited
   750 Heron Road
   Ottawa, Ontario
   Canada K1V 1A7

シャロンBoeyenは株式会社750サギのRoadオタワ、技術オンタリオカナダK1V 1A7をゆだねます。

   EMail: sharon.boeyen@entrust.com

メール: sharon.boeyen@entrust.com

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA

ティムハウズネットスケープ・コミュニケーションズ501E.Middlefield通り マウンテンビュー、カリフォルニア94043米国

   EMail: howes@netscape.com

メール: howes@netscape.com

   Patrick Richard
   Xcert Software Inc.
   Suite 1001, 701 W. Georgia Street
   P.O. Box 10145
   Pacific Centre
   Vancouver, B.C.
   Canada V7Y 1C6

パトリック・リチャード・Xcertソフトウェア株式会社Suite1001、701w.ジョージア私書箱10145の太平洋の通りセンターB.C.バンクーバー(カナダ)V7Y 1C6

   EMail: patr@xcert.com

メール: patr@xcert.com

Boeyen, et al.              Standards Track                     [Page 7]

RFC 2587                   PKIX LDAPv2 Schema                  June 1999

Boeyen、他 規格はPKIX LDAPv2図式1999年6月にRFC2587を追跡します[7ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。

Boeyen, et al.              Standards Track                     [Page 8]

Boeyen、他 標準化過程[8ページ]