RFC2559 日本語訳

Network Working Group                                      S. Boeyen
Request for Comments: 2559                                   Entrust
Updates: 1778                                               T. Howes
Category: Standards Track                                   Netscape
                                                          P. Richard
                                                               Xcert
                                                          April 1999

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

                Internet X.509 Public Key Infrastructure
                     Operational Protocols - LDAPv2

インターネットの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 protocol described in this document is designed to satisfy some
   of the operational requirements within the Internet X.509 Public Key
   Infrastructure (IPKI).  Specifically, this document addresses
   requirements to provide access to Public Key Infrastructure (PKI)
   repositories for the purposes of retrieving PKI information and
   managing that same information.  The mechanism described in this
   document is based on the Lightweight Directory Access Protocol (LDAP)
   v2, defined in RFC 1777, defining a profile of that protocol for use
   within the IPKI and updates encodings for certificates and revocation
   lists from RFC 1778. Additional mechanisms addressing PKIX
   operational requirements are specified in separate documents.

本書では説明されたプロトコルは、インターネットX.509公開鍵暗号基盤(IPKI)の中で操作上の要件のいくつかを満たすように設計されています。 明確に、このドキュメントは、公開鍵暗号基盤(PKI)倉庫へのアクセスをPKI情報を検索する目的に提供するという要件と管理がその同じ情報であると扱います。 本書では説明されたメカニズムは、IPKIとアップデートencodingsの中の証明書と取消しリストの使用のためにRFC1778からそのプロトコルのプロフィールを定義しながら、RFC1777で定義されたライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)v2に基づいています。 操作上の要件をPKIXに扱う追加メカニズムが別々のドキュメントで指定されます。

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

キーワード'MUST'、'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. This
   specification addresses requirements to provide retrieval of X.509
   PKI information, including certificates and CRLs from a repository.
   This specification also addresses requirements to add, delete and

この仕様はインターネットへの公開鍵暗号基盤(PKI)の開発の複合規格の一部です。 この仕様は倉庫から証明書とCRLsを含むX.509 PKI情報の検索を提供するという要件を扱います。 そしてまた、この仕様が加えるという要件を扱う、削除。

Boeyen, et al.              Standards Track                     [Page 1]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[1ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

   modify PKI information in a repository. A profile based on the LDAP
   version 2 protocol is provided to satisfy these requirements.

倉庫でPKI情報を変更してください。 これらの要件を満たすためにLDAPバージョン2プロトコルに基づくプロフィールを提供します。

3.  Model

3. モデル

   The PKI components, as defined in PKIX Part 1, which are involved in
   PKIX operational protocol interactions include:

PKIの部品であり、PKIX Part1で定義されるようにどれがPKIXの操作上のプロトコル相互作用にかかわるか定義されます。

      -  End Entities
      -  Certification Authorities (CA)
      -  Repository

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

   End entities and CAs using LDAPv2, retrieve PKI information from the
   repository using a subset of the LDAPv2 protocol.

LDAPv2を使用して、実体とCAsを終わらせてください、そして、LDAPv2プロトコルの部分集合を使用することで倉庫からのPKI情報を検索してください。

   CAs populate the repository with PKI information using a subset of
   the LDAPv2 protocol.

LDAPv2プロトコルの部分集合を使用することでCAsはPKI情報で倉庫に居住します。

4.  Lightweight Directory Access Protocol (LDAP)

4. ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)

   The following sections examine the retrieval of PKI information from
   a repository and management of PKI information in a repository. A
   profile of the LDAPv2 protocol is defined for providing these
   services.

以下のセクションは倉庫でのPKI情報の倉庫と管理からPKI情報の検索を調べます。 LDAPv2プロトコルのプロフィールは、これらのサービスを提供するために定義されます。

   Section 5 satisfies the requirement to retrieve PKI information (a
   certificate, CRL, or other information of interest) from an entry in
   the repository, where the retrieving entity (either an end entity or
   a CA) has knowledge of the name of the entry. This is termed
   "repository read".

セクション5は倉庫のエントリーからPKI情報(興味深い証明書、CRL、または他の情報)を検索するという要件を満たします。そこでは、検索実体(終わりの実体かカリフォルニアのどちらか)はエントリーの名前に関する知識を持っています。 これは「倉庫は読んだ」と呼ばれます。

   Section 6 satisfies the same requirement as 5 for the situation where
   the name of the entry is not known, but some other related
   information which may optionally be used as a filter against
   candidate entries in the repository, is known.  This is termed
   "repository search".

セクション6は、エントリーの名前が知られていない状況のための5として同じ要件を満たしますが、倉庫でフィルタとして任意に候補エントリーに対して使用されるかもしれないある他の関連情報を満たして、知られています。 これは「倉庫検索」と呼ばれます。

   Section 7 satisfies the requirement of CAs to add, delete and modify
   PKI information information (a certificate, CRL, or other information
   of interest)in the repository. This is termed "repository modify".

セクション7はCAsが倉庫でPKI情報情報(興味深い証明書、CRL、または他の情報)を加えて、削除して、変更するという要件を満たします。 これは呼ばれます。「倉庫は変更します」。

   The subset of LDAPv2 needed to support each of these functions is
   described below.  Note that the repository search service is a
   superset of the repository read service in terms of the LDAPv2
   functionality needed.

それぞれのこれらの機能をサポートするのが必要であるLDAPv2の部分集合は以下で説明されます。 倉庫サーチサービスがサービスが機能性が必要としたLDAPv2に関して読まれた倉庫のスーパーセットであることに注意してください。

   Note that all tags are implicit by default in the ASN.1 definitions
   that follow.

すべてのタグがデフォルトで続くASN.1定義で内在していることに注意してください。

Boeyen, et al.              Standards Track                     [Page 2]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[2ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

5.  LDAP Repository Read

5. LDAP倉庫は読みました。

   To retrieve information from an entry corresponding to the subject or
   issuer name of a certificate, requires a subset of the following
   three LDAP operations:

証明書の対象か発行人名に対応するエントリーから情報を検索して、以下の3つのLDAP操作の部分集合を必要とします:

     BindRequest (and BindResponse)
     SearchRequest (and SearchResponse)
     UnbindRequest

BindRequest(そして、BindResponse)SearchRequest(そして、SearchResponse)UnbindRequest

   The subset of each REQUIRED operation is given below.

それぞれのREQUIRED操作の部分集合を以下に与えます。

5.1.  Bind

5.1. ひも

5.1.1.  Bind Request

5.1.1. ひもの要求

   The full LDAP v2 Bind Request is defined in RFC 1777.

完全なLDAP v2 Bind RequestはRFC1777で定義されます。

   An application providing a LDAP repository read service MUST
   implement the following subset of this operation:

サービスが読まれたLDAP倉庫を提供するアプリケーションはこの操作の以下の部分集合を実装しなければなりません:

      BindRequest ::=
        [APPLICATION 0] SEQUENCE {
           version      INTEGER (2),
           name         LDAPDN, -- MUST accept NULL LDAPDN
           simpleauth [0] OCTET STRING  -- MUST accept NULL simple
           }

BindRequest:、:= [アプリケーション0] 系列バージョンINTEGER(2)、名前LDAPDN--NULL LDAPDN simpleauth[0]OCTET STRING--NULLが簡単であると受け入れなければならないと受け入れなければなりません。

   An application providing a LDAP repository read service MAY implement
   other aspects of the BindRequest as well.

サービスが読まれたLDAP倉庫を提供するアプリケーションはまた、BindRequestの他の局面を実装するかもしれません。

   Different services may have different security requirements.  Some
   services may allow anonymous search, others may require
   authentication. Those services allowing anonymous search may choose
   only to allow search based on certain criteria and not others.

異なったサービスには、異なったセキュリティ要件があるかもしれません。 いくつかのサービスが匿名の検索を許すかもしれなくて、他のものは認証を必要とするかもしれません。 匿名の検索を許すと単に許容するのが選ばれるかもしれないそれらのサービスは他のものではなく、ある評価基準に基づいて探されます。

   A LDAP repository read service SHOULD implement some level of
   anonymous search access. A LDAP repository read service MAY implement
   authenticated search access.

LDAP倉庫は何らかのレベルの匿名の検索アクセサリーをSHOULDが実装するサービスに読み込みました。 サービスが読まれたLDAP倉庫は認証された検索アクセサリーを実装するかもしれません。

5.1.2.  Bind Response

5.1.2. ひもの応答

   The full LDAPv2 BindResponse is described in RFC 1777.

完全なLDAPv2 BindResponseはRFC1777で説明されます。

   An application providing a LDAP repository read service MUST
   implement this entire protocol element, though only the following
   error codes may be returned from a Bind operation:

サービスが読まれたLDAP倉庫を提供するアプリケーションはこの全体のプロトコル要素を実装しなければなりません、Bind操作から以下のエラーコードだけを返してもよいのですが:

Boeyen, et al.              Standards Track                     [Page 3]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[3ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

       success                      (0),
       operationsError              (1),
       protocolError                (2),
       authMethodNotSupported       (7),
       noSuchObject                 (32),
       invalidDNSyntax              (34),
       inappropriateAuthentication  (48),
       invalidCredentials           (49),
       busy                         (51),
       unavailable                  (52),
       unwillingToPerform           (53),
       other                        (80)

成功(0)、operationsError(1)、protocolError(2)、authMethodNotSupported(7)、noSuchObject(32)、invalidDNSyntax(34)、inappropriateAuthentication(48)(invalidCredentials(49))は(51)と忙しくします、入手できない(52)、unwillingToPerform(53)、他です。(80)

5.2.  Search

5.2. 検索

5.2.1.  Search Request

5.2.1. 検索要求

   The full LDAPv2 SearchRequest is defined in RFC 1777.

完全なLDAPv2 SearchRequestはRFC1777で定義されます。

   An application providing a LDAP repository read service MUST
   implement the following subset of the SearchRequest.

サービスが読まれたLDAP倉庫を提供するアプリケーションはSearchRequestの以下の部分集合を実装しなければなりません。

      SearchRequest ::=
        [APPLICATION 3] SEQUENCE {
           baseObject     LDAPDN,
           scope             ENUMERATED {
                             baseObject   (0),
                                        },
           derefAliases   ENUMERATED {
                             neverDerefAliases   (0),
                                     },
           sizeLimit      INTEGER (0),
           timeLimit      INTEGER (0),
           attrsOnly      BOOLEAN, -- FALSE only
           filter         Filter,
           attributes     SEQUENCE OF AttributeType
                               }

SearchRequest:、:= [アプリケーション3] 系列baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、derefAliases ENUMERATED、neverDerefAliases(0)、sizeLimit INTEGER(0)、attrsOnlyブールのtimeLimit INTEGER(0)--FALSEがFilterをフィルターにかけるだけである、属性SEQUENCE OF AttributeType

      Filter ::=
        CHOICE {
          present        [7] AttributeType, -- "objectclass" only
                 }

以下をフィルターにかけてください:= 選択{[7] AttributeTypeを寄贈してください--"objectclass"専用}

   This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
   operation: a base object search with a filter testing for the
   existence of the objectClass attribute.

LDAPv2 SearchRequestのこの部分集合は操作が「読まれた」LDAPv2を許容します: フィルタがobjectClass属性の存在がないかどうか検査されているベースオブジェクト検索。

Boeyen, et al.              Standards Track                     [Page 4]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[4ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

   An application providing a LDAP repository read service MAY implement
   other aspects of the SearchRequest as well.

サービスが読まれたLDAP倉庫を提供するアプリケーションはまた、SearchRequestの他の局面を実装するかもしれません。

5.2.2.

5.2.2.

   The full LDAPv2 SearchResponse is defined in RFC 1777.

完全なLDAPv2 SearchResponseはRFC1777で定義されます。

   An application providing a LDAP repository read service over LDAPv2
   MUST implement the full SearchResponse.

サービスオーバーLDAPv2が読まれたLDAP倉庫を提供するアプリケーションは完全なSearchResponseを実装しなければなりません。

   Note that in the case of multivalued attributes such as
   userCertificate a SearchResponse containing this attribute will
   include all values, assuming the requester has sufficient access
   permissions.  The application/relying party may need to select an
   appropriate value to be used. Also note that retrieval of a
   certificate from a named entry does not guarantee that the
   certificate will include that same Distinguished Name (DN) and in
   some cases the subject DN in the certificate may be NULL.

userCertificateなどの多値の属性の場合では、この属性を含むSearchResponseがすべての値を含むことに注意してください、リクエスタには十分なアクセス許容があると仮定して。 アプリケーション/信用パーティーは、適切な値が使用されるのを選択する必要があるかもしれません。 また、命名されたエントリーからの証明書の検索が、証明書が証明書にその同じDistinguished Name(DN)といくつかの場合対象のDNを含むのを保証しないというメモはNULLであるかもしれません。

5.3.  Unbind

5.3. 解きます。

   The full LDAPv2 UnbindRequest is defined in RFC 1777.

完全なLDAPv2 UnbindRequestはRFC1777で定義されます。

   An application providing a LDAP repository read service MUST
   implement the full UnbindRequest.

サービスが読まれたLDAP倉庫を提供するアプリケーションは完全なUnbindRequestを実装しなければなりません。

6.  LDAP Repository Search

6. LDAP倉庫検索

   To search, using arbitrary criteria, for an entry in a repository
   containing a certificate, CRL, or other information of interest,
   requires a subset of the following three LDAP operations:

証明書を含む倉庫でエントリーの任意の評価基準を使用して、探すために、興味があるCRL、または他の情報が以下の3つのLDAP操作の部分集合を必要とします:

     BindRequest (and BindResponse)
     SearchRequest (and SearchResponse)
     UnbindRequest

BindRequest(そして、BindResponse)SearchRequest(そして、SearchResponse)UnbindRequest

   The subset of each operation REQUIRED is given below.

各操作REQUIREDの部分集合を以下に与えます。

6.1.  Bind

6.1. ひも

   The BindRequest and BindResponse subsets needed are the same as those
   described in Section 5.1.

部分集合が必要としたBindRequestとBindResponseはものがセクション5.1で説明したのと同じです。

   The full LDAP v2 Bind Request is defined in RFC 1777.

完全なLDAP v2 Bind RequestはRFC1777で定義されます。

Boeyen, et al.              Standards Track                     [Page 5]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[5ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

6.2.  Search

6.2. 検索

6.2.1.  Search Request

6.2.1. 検索要求

   The full LDAPv2 SearchRequest is defined in RFC 1777.

完全なLDAPv2 SearchRequestはRFC1777で定義されます。

   An application providing a LDAP repository search service MUST
   implement the following subset of the SearchRequest protocol unit.

LDAP倉庫サーチサービスを提供するアプリケーションはSearchRequestプロトコルユニットの以下の部分集合を実装しなければなりません。

      SearchRequest ::=
        [APPLICATION 3] SEQUENCE {
           baseObject     LDAPDN,
           scope          ENUMERATED {
                               baseObject     (0),
                               singleLevel    (1),
                               wholeSubtree   (2)
                                     },
           derefAliases   ENUMERATED {
                               neverDerefAliases     (0),
                                     },
           sizeLimit      INTEGER (0 .. maxInt),
           timeLimit      INTEGER (0 .. maxInt),
           attrsOnly      BOOLEAN,  -- FALSE only
           filter         Filter,
           attributes     SEQUENCE OF AttributeType
                                }

SearchRequest:、:= [アプリケーション3] 系列baseObject LDAPDN、範囲ENUMERATED、baseObject(0)、singleLevel(1)、wholeSubtree(2)、derefAliases ENUMERATED、neverDerefAliases(0)、sizeLimit INTEGER(0maxInt)、attrsOnlyブールのtimeLimit INTEGER(0maxInt)--FALSEがFilterをフィルターにかけるだけである、属性SEQUENCE OF AttributeType

   All aspects of the SearchRequest MUST be supported, except for the
   following:

以下を除いて、SearchRequestの全面をサポートしなければなりません:

   - Only the neverDerefAliases value of derefAliases needs to be
     supported

- derefAliasesのneverDerefAliases値だけが、サポートされる必要があります。

   - Only the FALSE value for attrsOnly needs to be supported

- attrsOnlyのためのFALSE値だけが、サポートされる必要があります。

   This subset provides a more general search capability.  It is a
   superset of the SearchRequest subset defined in Section 5.2.1. The
   elements added to this service are:

この部分集合は、より一般的な検索能力を提供します。 それはセクション5.2.1で定義されたSearchRequest部分集合のスーパーセットです。 このサービスに加えられた要素は以下の通りです。

   - singleLevel and wholeSubtree scope needs to be supported

- singleLevelとサポートするべきwholeSubtree範囲の必要性

   - sizeLimit is included

- sizeLimitは含まれています。

   - timeLimit is included

- timeLimitは含まれています。

   - Enhanced filter capability

- 高められたフィルタ能力

Boeyen, et al.              Standards Track                     [Page 6]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[6ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

   An application providing a LDAP repository search service MAY
   implement other aspects of the SearchRequest as well.

LDAP倉庫サーチサービスを提供するアプリケーションはまた、SearchRequestの他の局面を実装するかもしれません。

6.2.2.  Search Response

6.2.2. 検索応答

   The full LDAPv2 SearchResponse is defined in RFC 1777.

完全なLDAPv2 SearchResponseはRFC1777で定義されます。

   An application providing a LDAP repository search service over LDAPv2
   MUST implement the full SearchResponse.

LDAP倉庫サーチサービスをLDAPv2の上に供給するアプリケーションは完全なSearchResponseを実装しなければなりません。

6.3.  Unbind

6.3. 解きます。

   An application providing a LDAP repository search service MUST
   implement the full UnbindRequest.

LDAP倉庫サーチサービスを提供するアプリケーションは完全なUnbindRequestを実装しなければなりません。

7.  LDAP Repository Modify

7. LDAP倉庫は変更します。

   To add, delete and modify PKI information in a repository  requires a
   subset of the following LDAP operations:

倉庫でPKI情報を加えて、削除して、変更するのは以下のLDAP操作の部分集合を必要とします:

     BindRequest (and BindResponse)
     ModifyRequest (and ModifyResponse)
     AddRequest (and AddResponse)
     DelRequest (and DelResponse
     UnbindRequest

BindRequest(そして、BindResponse)ModifyRequest(そして、ModifyResponse)AddRequest(そして、AddResponse)DelRequest、(DelResponse UnbindRequest

   The subset of each operation REQUIRED is given below.

各操作REQUIREDの部分集合を以下に与えます。

7.1.  Bind

7.1. ひも

   The full LDAP v2 Bind Request is defined in RFC 1777.

完全なLDAP v2 Bind RequestはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the following subset of this operation:

LDAP倉庫がサービスを変更するなら、アプリケーションはこの操作の以下の部分集合を実装しなければなりません:

      BindRequest ::=
        [APPLICATION 0] SEQUENCE {
           version      INTEGER (2),
           name         LDAPDN,
           simpleauth [0] OCTET STRING
           }

BindRequest:、:= [アプリケーション0] 系列バージョンINTEGER(2)、名前LDAPDN、simpleauth[0]OCTET STRING

   A LDAP repository modify service MUST implement authenticated access.

LDAP倉庫が変更する、サービスは認証されたアクセサリーを実装しなければなりません。

   The BindResponse subsets needed are the same as those described in
   Section 5.1.2.

部分集合が必要としたBindResponseはものがセクション5.1.2で説明したのと同じです。

Boeyen, et al.              Standards Track                     [Page 7]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[7ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

7.2.  Modify

7.2. 変更します。

7.2.1.  Modify Request

7.2.1. 要求を変更してください。

   The full LDAPv2 ModifyRequest is defined in RFC 1777.

完全なLDAPv2 ModifyRequestはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the following subset of the ModifyRequest protocol unit.

LDAP倉庫がサービスを変更するなら、アプリケーションはModifyRequestプロトコルユニットの以下の部分集合を実装しなければなりません。

      ModifyRequest ::=
        [APPLICATION 6] SEQUENCE {
       object         LDAPDN,
       modification   SEQUENCE OF SEQUENCE {
                        operation     ENUMERATED {
                                        add     (0),
                                        delete  (1)
                                      },
                        modification  SEQUENCE {
                                      type   AttributeType,
                                      values SET OF
                                             AttributeValue
                                      }
                      }
        }

ModifyRequest:、:= [アプリケーション6] 系列LDAPDN、変更SEQUENCE OF SEQUENCEが反対する、操作ENUMERATEDは、(0) (1)を削除するように言い足して、変更SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします。

   All aspects of the ModifyRequest MUST be supported, except for the
   following:

以下を除いて、ModifyRequestの全面をサポートしなければなりません:

   - Only the add and delete values of operation need to be supported

- 唯一、サポートするべき操作の必要性の値を加えて、削除してください。

7.2.2.  Modify Response

7.2.2. 応答を変更してください。

   The full LDAPv2 ModifyResponse is defined in RFC 1777.

完全なLDAPv2 ModifyResponseはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the full ModifyResponse.

LDAP倉庫がサービスを変更するなら、アプリケーションは完全なModifyResponseを実装しなければなりません。

7.3.  Add

7.3. 加えてください。

7.3.1.  Add Request

7.3.1. 要求を加えてください。

   The full LDAPv2 AddRequest is defined in RFC 1777.

完全なLDAPv2 AddRequestはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the full AddRequest.

LDAP倉庫がサービスを変更するなら、アプリケーションは完全なAddRequestを実装しなければなりません。

Boeyen, et al.              Standards Track                     [Page 8]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[8ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

7.3.2.  Add Response

7.3.2. 応答を加えてください。

   The full LDAPv2 AddResponse is defined in RFC 1777.

完全なLDAPv2 AddResponseはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the full AddResponse.

LDAP倉庫がサービスを変更するなら、アプリケーションは完全なAddResponseを実装しなければなりません。

7.4.  Delete

7.4. 削除します。

7.4.1.  Delete Request

7.4.1. 要求を削除してください。

   The full LDAPv2 DelRequest is defined in RFC 1777.

完全なLDAPv2 DelRequestはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the full DelRequest.

LDAP倉庫がサービスを変更するなら、アプリケーションは完全なDelRequestを実装しなければなりません。

7.4.2.  Delete Response

7.4.2. 応答を削除してください。

   The full LDAPv2 DelResponse is defined in RFC 1777.

完全なLDAPv2 DelResponseはRFC1777で定義されます。

   An application providing a LDAP repository modify service MUST
   implement the full DelResponse.

LDAP倉庫がサービスを変更するなら、アプリケーションは完全なDelResponseを実装しなければなりません。

7.5.  Unbind

7.5. 解きます。

   An application providing a LDAP repository modify service MUST
   implement the full UnbindRequest.

LDAP倉庫がサービスを変更するなら、アプリケーションは完全なUnbindRequestを実装しなければなりません。

8.  Non-standard attribute value encodings

8. 標準的でない属性値encodings

   When conveyed in LDAP requests and results, attributes defined in
   X.500 are to be encoded using string representations defined in RFC
   1778, The String Representation of Standard Attribute Syntaxes.
   These string encodings were based on the attribute definitions from
   X.500(1988).  Thus, the string representations of the PKI information
   elements are for version 1 certificates and version 1 revocation
   lists.  Since this specification uses version 3 certificates and
   version 2 revocation lists, as defined in X.509(1997), the RFC 1778
   string encoding of these attributes is inappropriate.

LDAP要求と結果で運ばれると、X.500で定義された属性はRFC1778で定義されたストリング表現を使用することでコード化されることです、Standard Attribute SyntaxesのString Representation。 これらのストリングencodingsはX.500(1988)からの属性定義に基づきました。 したがって、PKI情報要素のストリング表現はバージョン1証明書とバージョン1取消しリストのためのものです。 この仕様がバージョン3証明書とバージョン2取消しリストを使用するので、X.509(1997)で定義されるように、これらの属性のRFC1778ストリングコード化は不適当です。

   For this reason, these attributes MUST be encoded using a syntax
   similar to the syntax "Undefined" from section 2.1 of RFC 1778:
   values of these attributes are encoded as if they were values of type
   "OCTET STRING", with the string value of the encoding being the DER-
   encoding of the value itself.  For example, when writing a
   userCertificate to the repository, the CA generates a DER-encoding of
   the certificate and uses that encoding as the value of the
   userCertificate attribute in the LDAP Modify request.This encoding

この理由で、RFC1778のセクション2.1から「未定義」の構文と同様の構文を使用して、これらの属性をコード化しなければなりません: これらの属性の値はまるでそれらがタイプ「八重奏ストリング」の値であるかのようにコード化されます、価値自体のDERコード化であるコード化のストリング値で。 例えば、倉庫へのuserCertificateに書くとき、カリフォルニアは、証明書のDER-コード化を生成して、LDAP Modify request.Thisコード化における、userCertificate属性の値としてそのコード化を使用します。

Boeyen, et al.              Standards Track                     [Page 9]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[9ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

   style is consistent with the encoding scheme proposed for LDAPv3,
   which is now being defined within the IETF.

スタイルは現在IETFの中で定義されているLDAPv3のために提案されたコード化体系と一致しています。

   Note that certificates and revocation lists will be transferred using
   this mechanism rather than the string encodings in RFC 1778 and
   client systems which do not understand this encoding may experience
   problems with these attributes.

証明書と取消しリストがこのコード化がこれらの属性に関する問題を経験するかもしれないのを理解していないRFC1778とクライアントシステムでストリングencodingsよりむしろこのメカニズムを使用することで移されることに注意してください。

9.  Transport

9. 輸送

   An application providing a LDAP repository read service, LDAP
   repository search service, or LDAP repository modify service MUST
   support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
   1777.

読書サービス、LDAP倉庫サーチサービス、またはLDAP倉庫が変更するa LDAP倉庫にサービスを供給するアプリケーションは、LDAPv2がTCPの上の輸送であるとサポートしなければなりません、RFC1777のセクション3.1で定義されるように。

   An application providing a LDAP repository read service, LDAP
   repository search service, or LDAP repository modify service MAY
   support LDAPv2 transport over other reliable transports as well.

サービスが読まれたLDAP倉庫、LDAP倉庫サーチサービス、またはLDAPに倉庫を供給するアプリケーションはまた、他の信頼できる輸送の上のサービス5月のサポートLDAPv2輸送を変更します。

10.  Security Considerations

10. セキュリティ問題

   Since the elements of information which are key to the PKI service
   (certificates and CRLs) are both digitally signed pieces of
   information, additional integrity service is NOT REQUIRED.  As
   neither information element need be kept secret and anonymous access
   to such information, for retrieval purposes is generally acceptable,
   privacy service is NOT REQUIRED for information retrieval requests.

情報のPKIサービス(証明書とCRLs)に主要な要素が情報の断片であるとデジタルにともに署名されるので、追加保全サービスはNOT REQUIREDです。 要素が検索目的のためのそのような情報への秘密の、そして、匿名のアクセスであることが保たれなければならないというどちらの情報も一般に許容できないとき、プライバシーサービスは情報検索要求のためのNOT REQUIREDです。

   CAs have additional requirements, including modification of PKI
   information.  Simple authentication alone is not sufficient for these
   purposes. It is RECOMMENDED that some stronger means of
   authentication and/or (if simple authentication is used) some means
   of protecting the privacy of the password is used, (e.g.  accept
   modifications only via physically secure networks, use IPsec, use SSH
   or TLS or SSL tunnel). Without such authentication, it is possible
   that a denial-of-service attack could occur where the attacker
   replaces valid certificates with bogus ones.

CAsには、PKI情報の変更を含む追加要件があります。 簡易認証だけがこれらの目的のために十分ではありません。 認証のいくつかの、より強い手段、そして/または、パスワードのプライバシーを保護するいくつかの(簡易認証が使用されているなら)手段が使用されているのが、RECOMMENDEDである、(IPsecを使用するか、SSHを使用する、例えば、肉体的に安全なネットワークを通してだけ変更を受け入れてください。さもないと、TLSかSSLがトンネルを堀ります。) そのような認証がなければ、サービス不能攻撃が攻撃者が有効な証明書をにせのものに取り替えるところに起こることができたのは、可能です。

   For the LDAP repository modify service, profiled in section 7, there
   are some specific security considerations with respect to access
   control. These controls apply to a repository which is under the same
   management control as the CA. Organizations operating directories are
   NOT REQUIRED to provide external CAs access permission to their
   directories.

セクション7でサービスを変更して、輪郭を描かれたLDAP倉庫には、アクセスコントロールに関していくつかの特定のセキュリティ問題があります。 これらのコントロールはカリフォルニアと同じマネジメント・コントロールの下にある倉庫に申請されます。 ディレクトリを運用する組織は外部のCAs参照許可を彼らのディレクトリに供給するNOT REQUIREDです。

Boeyen, et al.              Standards Track                    [Page 10]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[10ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

   The CA MUST have access control permissions allowing it to:

カリフォルニアには、以下のことをそれは許容するアクセス制御許容がなければなりません。

      For CA entries:
         - add, modify and delete all PKI attributes for its own
           directory entry;
         - add, modify and delete all values of these attributes.

カリフォルニアのエントリーに: - それ自身のディレクトリエントリのためにすべてのPKI属性を加えて、変更して、削除してください。 - これらの属性のすべての値を加えて、変更して、削除してください。

      For CRL distribution point entries (if used):
         - create, modify and delete entries of object class
           cRLDistributionPoint immediately subordinate to its own
           entry;
         - add, modify and delete all attributes, and all values of
           these attributes for these entries.

CRL分配ポイントエントリー(使用されるなら)に: - cRLDistributionPointがすぐにそれ自身のエントリーに下位に置かせるオブジェクトのクラスのエントリーを作成して、変更して、削除してください。 - すべての属性、およびこれらの属性のすべての値をこれらのエントリーに加えて、変更して、削除してください。

      For subscriber (end-entity) entries:
         - add, modify and delete the attribute userCertificate and all
           values of that attribute, issued by this CA to/from these
           entries.

加入者(終わり実体)エントリーに: - このカリフォルニアによってこれらのエントリーからの/に発行されたその属性の属性userCertificateとすべての値を加えて、変更して、削除してください。

   The CA is the ONLY entity with these permissions.

カリフォルニアはこれらの許容がある唯一の実体です。

   An application providing LDAP repository read, LDAP repository
   search, or LDAP repository modify service as defined in this
   specification is NOT REQUIRED to implement any additional security
   features other than those described herein, however an implementation
   SHOULD do so.

この仕様に基づき定義されて、LDAP倉庫が読んだ提供、LDAP倉庫検索、またはLDAP倉庫がサービスを変更するアプリケーションはどんな追加担保もしかしながら、ここに説明されたもの、したがってSHOULDがそうする実装以外の特徴であると実装するNOT REQUIREDです。

11.  References

11. 参照

   [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]  Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
        Representation of Standard Attribute Syntaxes", RFC 1778, March
        1995.

[2] ハウズとT.とKilleとS.とYeongとW.とC.ロビンス、「標準の属性構文のストリング表現」、RFC1778、1995年3月。

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

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

Boeyen, et al.              Standards Track                    [Page 11]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[11ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

12.  Authors' Addresses

12. 作者のアドレス

   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 12]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999

Boeyen、他 標準化過程[12ページ]RFC2559のPKIXの操作上のプロトコル--LDAPv2 April 1999

13.  Full Copyright Statement

13. 完全な著作権宣言文

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Boeyen, et al.              Standards Track                    [Page 13]

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