RFC2649 日本語訳

Network Working Group                                       B. Greenblatt
Request for Comments: 2649                                     P. Richard
Category: Experimental                                        August 1999

コメントを求めるワーキンググループB.グリーンブラット要求をネットワークでつないでください: 2649年のP.リチャードカテゴリ: 実験的な1999年8月

      An LDAP Control and Schema for Holding Operation Signatures

引き延ばし作戦署名のためのLDAPコントロールと図式

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Abstract

要約

   In many environments clients require the ability to validiate the
   source and integrity of information provided by the directory.  This
   document describes an LDAP message control which allows for the
   retrieval of digitally signed information. This document defines an
   LDAP v3 based mechanism for signing directory operations in order to
   create a secure journal of changes that have been made to each
   directory entry.  Both client and server based signatures are
   supported.  An object class for subsequent retrieval are "journal
   entries" is also defined.  This document specifies LDAP v3 controls
   that enable this functionality.  It also defines an LDAP v3 schema
   that allows for subsequent browsing of the journal information.

多くの環境で、クライアントは情報のソースと保全がディレクトリで提供したvalidiateへの能力を必要とします。 このドキュメントはデジタルに署名している情報の検索を考慮するLDAPメッセージ制御を説明します。 このドキュメントは、各ディレクトリエントリにされた変更の安全なジャーナルを作成するためにディレクトリ操作に署名するためにLDAP v3のベースのメカニズムを定義します。 両方のクライアントとサーバに基づいている署名はサポートされます。 その後の検索のためのオブジェクトのクラスはまた、「仕訳記入」が定義されるということです。 このドキュメントはこの機能性を可能にするLDAP v3コントロールを指定します。 また、それはジャーナル情報のその後のブラウジングを考慮するLDAP v3図式を定義します。

Table of Contents

目次

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1 Audit Trail Mechanism  . . . . . . . . . . . . . . . . . . .   2
   1.2. Handling the Delete Operation . . . . . . . . . . . . . . .   5
   2. Signed Results Mechanism  . . . . . . . . . . . . . . . . . .   6
   3. Security Considerations and Other Notes   . . . . . . . . . .   7
   4. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . .   9
   6. Full Copyright Statement  . . . . . . . . . . . . . . . . . .  10

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1は道のメカニズム. . . . . . . . . . . . . . . . . . . 2 1.2を監査します。 取り扱い、操作. . . . . . . . . . . . . . . 5 2を削除してください。 結果がメカニズム. . . . . . . . . . . . . . . . . . 6 3であると署名しました。 セキュリティ問題と他の注意. . . . . . . . . . 7 4。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 8 5。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 9 6。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 10

Greenblatt & Richard          Experimental                      [Page 1]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[1ページ]RFC2649LDAP Control、および図式1999年8月

1.  Introduction

1. 序論

   In many environments clients require the ability to validiate the
   source and integrity of information provided by the directory.  This
   document describes an LDAP message control which allows for the
   retrieval of digitally signed information.  The perspective of this
   document is that the origin of the information that is stored in LDAP
   v3 accessible directories is the LDAP v3 client that creates the
   information.  The source and integrity of the information is
   guaranteed by allowing for the digital signing of the operations that
   make changes to entries in the directory.  The source and integrity
   of an individual LDAP connection can be guaranteed by making use of
   an underlying session layer that provides such services, such as TLS.
   Note that the integrity of an individual connection does not, in and
   of itself guarantee the integrity of the data that comes across the
   connection.  This is due to the fact that the LDAP server is only
   capable of providing information that it has stored.  In distributed
   and replicated environments, the fact that an entry has been
   successfully retrieved from a server may not be completely
   reassuring, if the entry in question was replicated from an untrusted
   domain.

多くの環境で、クライアントは情報のソースと保全がディレクトリで提供したvalidiateへの能力を必要とします。 このドキュメントはデジタルに署名している情報の検索を考慮するLDAPメッセージ制御を説明します。 このドキュメントの見解はLDAP v3のアクセス可能なディレクトリに保存される情報の発生源が情報を作成するLDAP v3クライアントであるということです。 情報のソースと保全は、ディレクトリでエントリーへの変更を行う操作のデジタル署名を考慮することによって、保証されます。 それがそのようなサービスを提供するのを基本的なセッション層を利用することによって、個々のLDAP接続のソースと保全を保証できます、TLSなどのように。 個々の接続の保全がそうしないことに注意してください、そして、そういうものとして接続に出くわすデータの保全を保証してください。 これはLDAPサーバがそれが保存した情報を提供できるだけであるという事実のためです。 分配されて模写された環境で、サーバからエントリーを首尾よく検索してあるという事実は完全に心強いかもしれないというわけではありません、問題のエントリーが信頼されていないドメインから模写されたなら。

   By making use of public key technology, and creating digitally signed
   transactions that are created by the LDAP v3 client as entries are
   created and modified, a complete journal of the history of the entry
   is available.  Since each entry in the journal has been digitally
   signed with the private key of the creator, or modifier of the entry,
   the source and integrity of the directory entry can be validated by
   verifying the signature of each entry in the journal.  Note that not
   all of the journal entries will have been signed by the same user.

公開鍵技術を利用して、エントリーが作成されて、変更されるときLDAP v3クライアントによって作成されるデジタルに署名しているトランザクションを作成することによって、エントリーの歴史の完全なジャーナルは利用可能です。 クリエイターの秘密鍵、またはエントリーの修飾語をジャーナルにおける各エントリーとデジタルに契約してあるので、ジャーナルにおける、それぞれのエントリーの署名について確かめることによって、ディレクトリエントリのソースと保全を有効にすることができます。 仕訳記入のすべてが同じユーザによって署名されるというわけではなくてしまうだろうことに注意してください。

1.1.  Audit Trail Mechanism

1.1. 監査証跡メカニズム

   Signed directory operations is a straightforward application of
   S/MIME technology that also leverages the extensible framework that
   is provided by LDAP version 3.  LDAP version 3 is defined in [4], and
   S/MIME is defined in [2].  The security used in S/MIME is based in
   the definitions in [1].  The basic idea is that the submitter of an
   LDAP operation that changes the directory information includes an
   LDAP version 3 control that includes either a signature of the
   operation, or a request that the LDAP server sign the operation on
   the behalf of the LDAP client.  The result of the operation (in
   addition to the change of the directory information), is additional
   information that is attached to directory objects, that includes the
   audit trail of signed operations.  The LDAP control is (OID =
   1.2.840.113549.6.0.0):

ディレクトリ操作であると署名されているのは、また、LDAPバージョン3によって提供される広げることができるフレームワークを利用するS/MIME技術の簡単な適用です。 LDAPバージョン3は[4]で定義されます、そして、S/MIMEは[2]で定義されます。 S/MIMEに使用されるセキュリティは[1]との定義で基づいています。 基本的な考え方はディレクトリ情報を変えるLDAP操作のsubmitterがLDAPクライアントに代わって操作の署名かLDAPサーバが操作に署名するという要求のどちらかを含んでいるLDAPバージョン3コントロールを含んでいるということです。 操作(ディレクトリ情報の変化に加えた)の結果はディレクトリオブジェクトに付けられていて、署名している操作の監査証跡を含んでいる追加情報です。 LDAPコントロールがそうである、(OID=1.2.840.113549、.6、.0、.0):

Greenblatt & Richard          Experimental                      [Page 2]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[2ページ]RFC2649LDAP Control、および図式1999年8月

      SignedOperation ::= CHOICE {
           signbyServer   NULL,
           signatureIncluded   OCTET STRING
       }

SignedOperation:、:= 選択ヌルsignbyServer signatureIncluded八重奏ストリング

   If the SignatureIncluded CHOICE is used, then the OCTET string is
   just an S/MIME message of the multipart/signed variety, that is
   composed of a single piece, that is the signature of the directory
   operation.  Multipart/signed MIME objects are defined in [3].  If the
   SignbyServer CHOICE us used, then the LDAP server creates the
   signature on behalf of the client, using its own identity and not the
   identity of the client, in order to produce the audit trail entry.
   In either case the successful result of processing the control is the
   creation of additional information in the directory entry that is
   being modified or created. The signature of the LDAP operation is
   computed on the LDAPMessage prior to the inclusion of the
   SignedOperation control. The procedure is as follows:

SignatureIncluded CHOICEが使用されているならOCTETストリングがただ複合の、または、署名しているバラエティーに関するS/MIMEメッセージである、それはすなわち、ただ一つの断片、ディレクトリ操作の署名で構成されます。 複合の、または、署名しているMIMEオブジェクトは[3]で定義されます。 SignbyServer CHOICEであるなら、私たちが使用されて、次に、LDAPサーバはクライアントを代表して署名を作成します、アイデンティティではなく、それ自身のクライアントのアイデンティティを使用して、監査証跡エントリーを起こすために。 どちらかの場合では、コントロールを加工処理するという好成績は変更されるか、または作成されているディレクトリエントリの追加情報の作成です。 LDAP操作の署名はSignedOperationコントロールの包含の前にLDAPMessageで計算されます。 手順は以下の通りです:

      - Build LDAPMessage without the SignedOperation control
      - Compute signature on the above LDAPMessage
      - Create new LDAPMessage that includes the old MessageID,
        protocolOp and any control fields from the previous LDAPMessage,
        plus  the computed signature formatted as an S/MIME message.

- SignedOperationコントロールなしでLDAPMessageを造ってください--上のLDAPMessageで署名を計算してください--前のLDAPMessage、およびS/MIMEメッセージとしてフォーマットされた計算された署名から古いMessageID、protocolOp、およびどんな制御フィールドも含んでいる新しいLDAPMessageを作成してください。

   No control is defined for the server to return in the LDAPResult as
   defined in [4].  The LDAP server MAY attempt to parse and verify the
   signature included in the SignedOperation control, but is not
   required to.  The server can accept the signed operation without
   verifying the signature.  Signature verification can be quite a
   lengthy operation, requiring complex certificate chain traversals.
   This allows a more timely creation of the audit trail by the server.
   Any LDAP client browsing the directory that retrieves the 'Changes'
   (defined in the following paragraphs) attributes, should verify the
   signature of each value according to the local signature verification
   policies.  Even if the LDAP server verifies the signature contained
   in the singed operation, the LDAP client has no way of knowing what
   policies were followed by the server in order to verify the
   signature.

コントロールは、全くサーバが[4]で定義されるようにLDAPResultで戻るように定義されません。 LDAPサーバは、SignedOperationコントロールに含まれていた署名について分析して、確かめるのを試みるかもしれませんが、必要ではありません。 署名について確かめないで、サーバは署名している操作を受け入れることができます。 複雑な証明書チェーン縦断を必要として、署名照合はかなり長い操作であるかもしれません。 これはサーバで監査証跡の、よりタイムリーな作成を許容します。どれかLDAPクライアントが'変化'(以下のパラグラフでは、定義される)属性を検索するディレクトリをブラウズする場合、ローカルの署名照合方針によると、それぞれの価値の署名について確かめるべきです。 LDAPサーバが表面を焼かれた操作に含まれた署名について確かめても、LDAPクライアントには、サーバが署名について確かめるためにどんな方針のあとに続いたかを知る方法が全くありません。

   If the LDAP server is unable to verify the signature and wishes to
   return an error then the error code unwillingToPerform(53) should be
   returned, and the entire LDAP operation fails.  In this situation, an
   appropriate message (e.g. "Unable to verify signature") MAY be
   included in the errorMessage of the LDAPResult.  The SignedOperation
   Control MAY be marked CRITICAL, and if it is CRITICAL then if the
   LDAP Server performs the LDAP operation, then must include the
   signature in the signedAuditTrail information.

LDAPサーバが署名について確かめることができないで、誤りを返したいなら、エラーコードunwillingToPerform(53)を返すべきです、そして、全体のLDAP操作は失敗します。 この状況で、適切なメッセージ(例えば、「署名について確かめることができない」)はLDAPResultのerrorMessageに含まれるかもしれません。 SignedOperation Controlは著しいCRITICALとLDAP ServerがLDAP操作を実行するならその時それがCRITICALであるかどうかということであるかもしれなく、次に、signedAuditTrail情報に署名を含まなければなりません。

Greenblatt & Richard          Experimental                      [Page 3]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[3ページ]RFC2649LDAP Control、および図式1999年8月

      The schema definition for the signedAuditTrail information is:

signedAuditTrail情報のための図式定義は以下の通りです。

      ( 1.2.840.113549.6.1.0
      NAME 'signedAuditTrail'
      SUP top
      AUXILIARY
      MUST (
      Changes
      )
         )

(1.2.840.113549.6.1.0NAME'signedAuditTrail'SUP先端AUXILIARY MUST(変化))

      The format of the Changes attribute is:

Changes属性の形式は以下の通りです。

      ( 1.2.840.113549.6.2.0
      NAME 'Changes'
      DESC 'a set of changes applied to an entry'
      SYNTAX 'Binary' )

(.0NAMEが'変化する'という1.2.840.113549.6.2DESC'1セットの変化はエントリーに適用された'SYNTAX'バイナリー')

      The actual format of the Changes attribute is:

Changes属性の実際の形式は以下の通りです。

      Changes ::= SEQUENCE {
           sequenceNumber [0] INTEGER (0 .. maxInt),
           signedOperation [1] OCTET STRING }

変化:、:= 系列sequenceNumber[0]整数(0maxInt)、signedOperation[1]八重奏ストリング

   The SignedOperation attribute is a multipart/signed S/MIME message.
   Part 1 of the message is the directory operation, and part 2 is the
   signature.  Sequence number 0 (if present) always indicates the
   starting point directory object as represented by the definitions in
   "A MIME Content-Type for Directory Information", as defined in [5].
   Subsequent sequence numbers indicate the sequence of changes that
   have been made to this directory object.  Note that the sequence of
   the changes can be verified due to the fact that the signed directory
   object will have a timestamp as part of the signature object, and
   that the sequence numbering as part of the change attribute should be
   considered to be an unverified aid to the LDAP client.  Sequence
   numbers are meaningful only within the context of a single directory
   entry, and LDAP servers are not expected to maintain these sequence
   numbers across all entries in the directory.

SignedOperation属性は複合の、または、署名しているS/MIMEメッセージです。 メッセージの第1部はディレクトリ操作です、そして、第2部は署名です。 一連番号0(存在しているなら)は「ディレクトリ情報のためのMIMEコンテントタイプ」との定義で表されるようにいつも出発点ディレクトリオブジェクトを示します、[5]で定義されるように。 その後の一連番号はこのディレクトリオブジェクトにされた変更の系列を示します。 署名しているディレクトリ目的には署名オブジェクトの一部としてタイムスタンプがあって、変化属性の一部としての系列付番がLDAPクライアントへの非検証された援助であると考えられるべきであるという事実のため変化の系列について確かめることができることに注意してください。 一連番号は単一ディレクトリエントリーの文脈だけの中で重要です、そして、LDAPサーバがディレクトリにおけるすべてのエントリーの向こう側にこれらの一連番号を維持しないと予想されます。

   Some LDAP servers will only allow operations that include the
   SignedOperation control.  This is indicated by the inclusion of a
   'signedDirectoryOperationSupport' attribute in the rootDSE.  This
   attribute is defined as:

いくつかのLDAPサーバがSignedOperationコントロールを含んでいる操作を許すだけでしょう。 これはrootDSEでの'signedDirectoryOperationSupport'属性の包含で示されます。 この属性は以下と定義されます。

Greenblatt & Richard          Experimental                      [Page 4]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[4ページ]RFC2649LDAP Control、および図式1999年8月

      1.2.840.113549.6.2.2
      NAME 'signedDirectoryOperationSupport'
      DESC 'how many of the LDAP operations must be signed'
      SYNTAX 'Integer' SINGLE-VALUE )

1.2.840.113549.6.2.2、NAME'signedDirectoryOperationSupport'DESC'LDAP操作のいくつ署名しなければならない'SYNTAX'整数'SINGLE-VALUE)

   The 'signedDirectoryOperationSupport' attribute above may have one of
   the values, '0', '1' or '2' with the following meanings:

上の'signedDirectoryOperationSupport'属性に、以下の意味がある値の1つ、'0'、'1'または'2'があるかもしれません:

      - '0' Directory Operations may be signed
      - '1' Directory Operations must always be signed
      - '2' Directory Operations must never be signed

- '0'ディレクトリOperationsが署名されるかもしれない''いつもディレクトリOperationsに署名しなければなりません--'2'という1ディレクトリOperationsに決して署名してはいけない。

   Some LDAP servers will desire that the audit trail be continuous, and
   not contain any gaps that would result from unsigned operations.
   Such server will include a signature on each LDAP operation that
   changes a directory entry, even when the LDAP client does not include
   a signed-Operation control.

いくつかのLDAPサーバは、監査証跡が連続していることを望んでいて、未署名の操作から生じるどんなギャップも含まないでしょう。 そのようなサーバはディレクトリエントリを変えるそれぞれのLDAP操作の署名を含むでしょう、LDAPクライアントが署名している運航管理を入れないと。

1.2.  Handling the Delete Operation

1.2. 取り扱い、操作を削除してください。

   The LDAP Delete operation represents an interesting case for Signed
   Directory Operations.  This is due to the case that subsequent to the
   successful completion of the Delete Operation, the object that would
   have held the latest 'Changes' attribute no longer exists.  In order
   to handle this situation, a new object class is defined to represent
   a directory object that has been deleted.

LDAP Delete操作はSignedディレクトリOperationsのためにおもしろいケースを表します。 これによるケースのため、Delete Operationの無事終了にその後です、最新のものを保持したオブジェクトが'変化する'というその属性がもう存在していないということです。 この状況を扱って、新しいオブジェクトのクラスは、削除されたディレクトリオブジェクトを表すために定義されます。

      ( 1.2.840.113549.6.1.2
      NAME 'zombieObject'
      SUP top
      STRUCTURAL
      MUST (
      Cn $ Changes $ OriginalObject
      )
         )

(1.2.840.113549.6.1.2NAME'zombieObject'SUP先端STRUCTURAL MUST(Cn$Changes$OriginalObject))

      The format of the OriginalObject attribute is:

OriginalObject属性の形式は以下の通りです。

      ( 1.2.840.113549.6.2.1
      NAME OriginalObject
      DESC 'The LDAP URL of an object that has been deleted from the
      directory' SYNTAX 'Binary' )

(1.2、'2進.840.113549.6.2.1NAME OriginalObject DESC'ディレクトリから削除されたオブジェクトのLDAP URL'SYNTAX')

   The OriginalObject attribute contains the URL of the object that was
   deleted from the directory.  It is formatted in accordance with RFC
   2255.  Directory servers that comply with this specification SHOULD
   create a zombieObject when performing the delete Operation that
   contains a SignedOperation LDAPControl.  The Cn attribute of the

OriginalObject属性はディレクトリから削除されたオブジェクトのURLを含んでいます。 RFC2255によると、それはフォーマットされます。 働くとき、この仕様SHOULDに従うディレクトリサーバがzombieObjectを作成する、SignedOperation LDAPControlを含むOperationを削除してください。 Cnは結果と考えます。

Greenblatt & Richard          Experimental                      [Page 5]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[5ページ]RFC2649LDAP Control、および図式1999年8月

   zombieObject is synthesized by the LDAP server, and may or may not be
   related to the original name of the directory entry that was deleted.
   All changes attributes that were attached to the original entry are
   copied over to the zombieObject.  In addition the LDAP Server MUST
   attach the signature of the Delete operation as the last successful
   change that was made to the entry.

zombieObjectはLDAPサーバによって統合されて、削除されたディレクトリエントリのオリジナルの名前に関連するかもしれません。 原始記入に付けられたすべての変化属性がzombieObjectにコピーされます。 さらに、LDAP Serverはエントリーにされた最後のうまくいっている変更としてDelete操作の署名を付けなければなりません。

2.  Signed Results Mechanism

2. 結果メカニズムであると署名されます。

   A control is also defined that allows the LDAP v3 client to request
   that the server sign the results that it returns.  It is intended
   that this control is primarily used in concert with the LDAPSearch
   operation.  This control MAY be marked as CRITICAL.  If it is marked
   as CRITICAL and the LDAP Server supports this operation, then all
   search results MUST be returned with a signature as attached in the
   SignedResult control if it is willing to sign results for this user.
   If the server supports this control but does not wish to sign the
   results for this user then the error code unwillingToPerform(53)
   should be returned, and the LDAP search will have failed.  In this
   situation, an appropriate message (e.g. "Unwilling to sign results
   for you!") MUST be included in the errorMessage of the LDAPResult.
   If the LDAPSigType has the value FALSE then the client is requesting
   that the server not sign this operation.  This may be done in
   situations where servers are configured to always sign their
   operations.

また、LDAP v3クライアントが、サーバが戻るという結果に署名するよう要求できるコントロールは定義されます。 このコントロールがLDAPSearch操作と協力して主として使用されることを意図します。 このコントロールはCRITICALとしてマークされるかもしれません。 それがCRITICALとしてマークされて、LDAP Serverがこの操作をサポートするなら、このユーザのために署名と共に結果に署名しても構わないと思っているならSignedResultコントロールで付けられるようにすべての検索結果を返さなければなりません。 サーバがこのコントロールをサポートしますが、このユーザのために結果に署名したくないなら、エラーコードunwillingToPerform(53)を返すべきです、そして、LDAP検索は失敗してしまうでしょう。 この状況、適切なメッセージ、(例えば、「あなたのために結果に署名するために不本意で!」、)、LDAPResultのerrorMessageに含まなければなりません。 LDAPSigTypeに値のFALSEがあるなら、クライアントは、サーバがこの操作に署名しないよう要求しています。 サーバがいつも彼らの操作に署名するために構成される状況でこれをするかもしれません。

   The LDAP control to include in the LDAP request is (OID =
   1.2.840.113549.6.0.1):

LDAP要求に含んでいるLDAPコントロールがそうである、(OID=1.2.840.113549、.6、.0、.1):

      DemandSignedResult ::=  LDAPSigType

DemandSignedResult:、:= LDAPSigType

      LDAPSigType ::= BOOLEAN

LDAPSigType:、:= 論理演算子

   In response to a DemandSignedResult control, the LDAP v3 server will
   return a SignedResult control in addition to the normal result as
   defined by the operation (assuming that the server understands the
   con- trol, and is willing to perform it).  The SignedResult control
   MUST NOT be marked CRITICAL.  Some LDAP v3 servers may be configured
   to sign all of their operations.  In this situation the server always
   returns a SignedResult control, unless instructed otherwise by the
   DemandSigne-dResult Control.  Since the SignedResult control is not
   marked critical, the LDAP client is allowed to ignore it.  The
   signature field below includes the signature of the enitre LDAPResult
   formatted as an S/MIME pkcs-7/signature object, as defined in [2].

DemandSignedResultコントロールに対応して、LDAP v3サーバは操作で定義されるように(サーバが、まやかしtrolを理解して、それを実行しても構わないと思っていると仮定して)正常な結果に加えたSignedResultコントロールを返すでしょう。 CRITICALであるとSignedResultコントロールをマークしてはいけません。 いくつかのLDAP v3サーバが、彼らの操作のすべてに署名するために構成されるかもしれません。 この状況で、別の方法でDemandSigne-dResult Controlによって命令されない場合、サーバはSignedResultコントロールをいつも返します。 SignedResultコントロールが重要であることはマークされないので、LDAPクライアントはそれを無視できます。 下の署名分野はS/MIME pkcs-7/署名オブジェクトとしてフォーマットされたenitre LDAPResultの署名を含んでいます、[2]で定義されるように。

Greenblatt & Richard          Experimental                      [Page 6]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[6ページ]RFC2649LDAP Control、および図式1999年8月

   The procedure for creating the signature of the signedResult control
   is the same as the procedure for the creation of the signedOperation
   control.  The LDAP control in the LDAP response is (OID =
   1.2.840.113549.6.0.2):

signedResultコントロールの署名を作成するための手順はsignedOperationコントロールの作成のための手順と同じです。 LDAP応答におけるLDAPコントロールがそうである、(OID=1.2.840.113549、.6、.0、.2):

      SignedResult ::= CHOICE {
           signature     OCTET STRING }

SignedResult:、:= 選択署名OCTET STRING

3.  Security Considerations and Other Notes

3. セキュリティ問題と他の注意

      The base OIDs are:

ベースOIDsは以下の通りです。

      rsadsiLdap ::= {1 2 840 113549 6}
      rsadsiLdapControls ::=  {1 2 840 113549 6 0}
      rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}
      rsadsiLdapAttributes ::= {1 2 840 113549 6 2}

rsadsiLdap:、:= 1 2、840、113549、6、rsadsiLdapControls:、:= 1 2、840、113549、6 0、rsadsiLdapObjectClasses:、:= 1 2、840、113549、6 1、rsadsiLdapAttributes:、:= {1 2 840 113549 6 2}

      The complete ASN.1 module for this specification is:

この仕様のための完全なASN.1モジュールは以下の通りです。

      SIGNEDOPERATIONS DEFINITIONS ::=
      BEGIN

SIGNEDOPERATIONS定義:、:= 始まってください。

      SignedOperation ::= CHOICE {
           signbyServer   NULL,
           signatureIncluded   OCTET STRING
       }

SignedOperation:、:= 選択ヌルsignbyServer signatureIncluded八重奏ストリング

      Changes ::= SEQUENCE {
           sequenceNumber [0] INTEGER (0 .. maxInt),
           signedOperation [1] OCTET STRING }

変化:、:= 系列sequenceNumber[0]整数(0maxInt)、signedOperation[1]八重奏ストリング

      DemandSignedResult ::=  LDAPSigType

DemandSignedResult:、:= LDAPSigType

      LDAPSigType ::= BOOLEAN

LDAPSigType:、:= 論理演算子

      SignedResult ::= CHOICE {
           signature     OCTET STRING }

SignedResult:、:= 選択署名OCTET STRING

      END

終わり

Greenblatt & Richard          Experimental                      [Page 7]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[7ページ]RFC2649LDAP Control、および図式1999年8月

   If any of the controls in this specification are supported by an LDAP
   v3 server then that server MUST make available its certificate (if
   any) in the userCertificate attribute of its rootDSE object.  The
   UserCertificate attribute is defined in [6], and contains the public
   key of the server that is used in the creation of the various
   signatures defined in this specification.

この仕様に基づくコントロールのどれかがLDAP v3サーバによってサポートされるなら、そのサーバで、rootDSEオブジェクトのuserCertificate属性における証明書(もしあれば)は利用可能にならなければなりません。 UserCertificate属性は、[6]で定義されて、この仕様に基づき定義された様々な署名の作成に使用されるサーバの公開鍵を含んでいます。

   It is not the intention of this specification to provide a mechanism
   that guarantees the origin and integrity of LDAP v3 operations.  Such
   a service is best provided by the use of an underlying protocol such
   as TLS [8].  TLS defines additional features such as encryption and
   compression.  This specification does not define support for
   encrypted operations.

LDAP v3操作の発生源と保全を保証するのは、この仕様がメカニズムを提供するという意志ではありません。 TLS[8]などの基本的なプロトコルの使用でそのようなサービスを最もよく提供します。 TLSは暗号化や圧縮などの付加的な機能を定義します。 この仕様は暗号化された操作のサポートを定義しません。

   This memo proposes protocol elements for transmission and storage of
   the digital signatures of LDAP operations.  Though the LDAP server
   may have verified the operation signatures prior to their storage and
   subsequent retrieval, it is prudent for LDAP clients to verify the
   signatures contained in the chained attribute upon their retrieval.
   The issuing Certification Authorities of the signer's certificate
   should also be consulted in order to determine if the signer's
   private key has been compromised or the certificate has been
   otherwise revoked.  Security considerations are discussed throughout
   this memo.

このメモはLDAP操作のデジタル署名のトランスミッションとストレージのためにプロトコル要素を提案します。 LDAPサーバは彼らのストレージとその後の検索の前に操作署名について確かめたかもしれませんが、LDAPクライアントが彼らの検索のチェーニングされた属性に含まれた署名について確かめるのは、慎重です。 また、署名者の証明書の発行しているCertification Authoritiesは、署名者の秘密鍵が感染されたか、または証明書が別の方法で取り消されたかを決定するために相談されるべきです。 このメモ中でセキュリティ問題について議論します。

4.  References

4. 参照

   [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5",
       RFC 2315, March 1998.

[1]Kaliski、B.、「PKCS7:」 暗号のメッセージ構文バージョン、15インチ、RFC2315、3月1998日

   [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
       Repka., "S/MIME Version 2 Message Specification", RFC 2311, March
       1998.

[2]のDusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.、およびL.Repka、「S/MIMEバージョン2メッセージ仕様」、RFC2311(1998年3月)

   [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
       Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
       RFC 1847, October 1995.

[3] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。

   [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
       Protocol (v3)", RFC 2251, December 1997.

[4] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。

   [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
       Directory Information", RFC 2425, September 1998.

[5] ハウズとT.とスミスとM.とF.ドーソン、「ディレクトリ情報のためのMIMEコンテントタイプ」、RFC2425、1998年9月。

   [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with
       LDAPv3", RFC 2256, December 1997.

[6] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaのSummary。」

Greenblatt & Richard          Experimental                      [Page 8]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[8ページ]RFC2649LDAP Control、および図式1999年8月

   [7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December
       1997.

[7] ハウズとT.とM.スミス、「LDAP URL形式」、RFC2255、1997年12月。

   [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
       2246, January 1999.

[8] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

5.  Authors' Addresses

5. 作者のアドレス

   Bruce Greenblatt
   San Jose, CA 95119
   USA

ブルース・グリーンブラット・カリフォルニア95119サンノゼ(米国)

   Phone: +1-408-224-5349
   EMail: bgreenblatt@directory-applications.com

以下に電話をしてください。 +1-408-224-5349 メールしてください: bgreenblatt@directory-applications.com

   Pat Richard
   Xcert Software, Inc.
   Suite 1001 - 701 W. Georgia
   Vancouver, BC
   CANADA V6G 1C9

リチャードXcertソフトウェアInc.スイート1001を軽くたたいてください--701w.ジョージアBCバンクーバー(カナダ)V6G 1C9

   EMail: patr@xcert.com

メール: patr@xcert.com

Greenblatt & Richard          Experimental                      [Page 9]

RFC 2649                LDAP Control and Schema              August 1999

グリーンブラット、リチャード実験的な[9ページ]RFC2649LDAP Control、および図式1999年8月

6.  Full Copyright Statement

6. 完全な著作権宣言文

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

Greenblatt & Richard          Experimental                     [Page 10]

グリーンブラットとリチャードExperimentalです。[10ページ]