Network Working Group B. Greenblatt
Request for Comments: 2649 P. Richard
Category: Experimental August 1999
An LDAP Control and Schema for Holding Operation Signatures
Status of this 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.
著作権（C）インターネット協会（1999）。全著作権所有。
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
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のクライアントによって作成されたデジタル署名されたトランザクションを作成することにより、エントリの歴史の完全なジャーナルが利用可能です。ジャーナル内の各エントリは、デジタルプライベートクリエーターのキー、またはエントリの修飾子で署名されているため、ディレクトリエントリのソースと整合性がジャーナルに各エントリの署名を検証することによって検証することができます。ジャーナルエントリのすべてではないが、同じユーザによって署名されていることに注意してください。
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 LDAPバージョン3によって提供される拡張可能なフレームワークを活用してS / MIME技術の直接的な適用は、[4]、及びS / MIMEで定義されている[2]で定義されています。 S / MIMEで使用されるセキュリティは、[1]の定義に基づいています。基本的な考え方は、ディレクトリ情報を変更するLDAP操作の提出者は、操作の署名、またはLDAPサーバがLDAPクライアントに代わって操作を署名要求のいずれかを含んでいるLDAPバージョン3コントロールが含まれていることです。 （ディレクトリ情報の変化に加えて）操作の結果は、署名された操作の監査証跡を含むディレクトリ・オブジェクトに添付される追加情報です。 LDAPコントロール（= 1.2.840.113549.6.0.0 OID）です。
SignedOperation ::= CHOICE {
signbyServer NULL,
signatureIncluded OCTET STRING
}
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が使用される場合、オクテット文字列がマルチパート/署名された種々のちょうどS / MIMEメッセージであり、それは、単一片から構成され、それは、ディレクトリ操作の署名です。マルチパート/ MIMEオブジェクトは、[3]で定義され署名されました。 SignbyServer CHOICE私たちが使用している場合、LDAPサーバは、監査証跡エントリを生成するために、独自のアイデンティティではなく、クライアントのIDを使用して、クライアントに代わって署名を作成します。いずれの場合においても制御の処理の成功した結果は、変更または作成されたディレクトリエントリの追加情報の作成です。 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.
- 上記たLDAPMessageに計算署名 - - SignedOperation制御なしたLDAPMessageビルド古いメッセージID、protocolOp及び前たLDAPMessage、プラスS / MIMEメッセージとしてフォーマット計算署名から任意の制御フィールドを含む新しいた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コントロールがCRITICALとマークされるかもしれない、とLDAPサーバーがLDAP操作を行った場合、それはその後、CRITICALであれば、その後、signedAuditTrail情報で署名を含める必要があります。
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.0 NAME 'signedAuditTrail' SUPトップ補助MUST（変更））
The format of the Changes attribute is:
変更属性の形式は次のとおりです。
( 1.2.840.113549.6.2.0 NAME 'Changes' DESC 'a set of changes applied to an entry' SYNTAX 'Binary' )
（1.2.840.113549.6.2.0 NAME「変更」DESC SYNTAX「バイナリ」「エントリに適用された変更のセット」）
The actual format of the Changes attribute is:
変更属性の実際の形式は次のとおりです。
Changes ::= SEQUENCE {
sequenceNumber [0] INTEGER (0 .. maxInt),
signedOperation [1] OCTET STRING }
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は、署名です。 [5]で定義されるように、「ディレクトリ情報のMIMEコンテンツタイプ」の定義で表されるように、シーケンス番号0（存在する場合）は、常に起点ディレクトリオブジェクトを示しています。以降のシーケンス番号は、このディレクトリオブジェクトに加えられた変更のシーケンスを示しています。変化の順序が原因署名したディレクトリオブジェクトが署名オブジェクトの一部として、タイムスタンプを持っているという事実に検証することができることに注意してください、と変化属性の一部として番号付けシーケンスは未検証への援助であると考えるべきであること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」属性を含めることによって示されます。この属性は、次のように定義されます
1.2.840.113549.6.2.2 NAME 'signedDirectoryOperationSupport' DESC 'how many of the LDAP operations must be signed' SYNTAX 'Integer' SINGLE-VALUE )
SYNTAX '整数' SINGLE-VALUE 'を署名する必要がありますどのようにLDAP操作の多くの' 1.2.840.113549.6.2.2 NAME 'signedDirectoryOperationSupport' DESC）
The 'signedDirectoryOperationSupport' attribute above may have one of the values, '0', '1' or '2' with the following meanings:
「signedDirectoryOperationSupport」属性は、上記次の意味を持つ値のいずれか、「0」、「1」又は「2」を有することができます。
- '0' Directory Operations may be signed - '1' Directory Operations must always be signed - '2' Directory Operations must never be signed
- 「0」ディレクトリ操作署名することができる - 「1」ディレクトリ操作は必ず署名しなければならないが - 「2」ディレクトリ操作は、署名されてはなりません
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操作の署名が含まれます。
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の削除操作は、署名付きディレクトリ操作のための興味深いケースを表します。これは、削除操作が正常に完了し、最新の「変更」属性がもう存在開催されなかっただろうオブジェクトへの以降の場合によるものです。この状況に対処するためには、新しいオブジェクトクラスが削除されたディレクトリ・オブジェクトを表すように定義されています。
( 1.2.840.113549.6.1.2 NAME 'zombieObject' SUP top STRUCTURAL MUST ( Cn $ Changes $ OriginalObject ) )
（1.2.840.113549.6.1.2 NAME 'zombieObject' SUPトップSTRUCTURAL MUST（CN $変更$ 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.840.113549.6.2.1 NAME OriginalObject DESC SYNTAX「バイナリ」「ディレクトリから削除されたオブジェクトのLDAPのURL」）
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 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.
OriginalObject属性は、ディレクトリから削除されたオブジェクトのURLが含まれています。それはSignedOperation LDAPControlが含まれている削除操作を実行するときzombieObjectを作成する必要があり、この仕様に準拠RFC 2255 Directoryサーバーに従ってフォーマットされています。 zombieObjectのCN属性は、LDAPサーバによって合成してもよく、または削除されたディレクトリエントリの元の名前に関連していない場合があります。元のエントリに添付されたすべての変更属性がzombieObjectにコピーされます。また、LDAPサーバはエントリに行われた最後の正常な変化として削除操作の署名を添付しなければなりません。
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サーバーがこの操作をサポートしている場合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制御（= 1.2.840.113549.6.0.1 OID）です。
DemandSignedResult ::= LDAPSigType
LDAPSigType ::= BOOLEAN
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のサーバーは、正常な結果に加えてSignedResult制御を戻します。 SignedResult制御がCRITICALとマークされてはなりません。一部のLDAP v3のサーバーでは、業務のすべてに署名するように構成することができます。 DemandSigne-dResultコントロールによって指示がない限り、このような状況では、サーバは常に、SignedResultコントロールを返します。 SignedResult制御が重要とマークされていないので、LDAPクライアントは、それを無視することが許可されています。署名フィールドは、以下に定義されるように、S / MIMEのPKCS-7 /署名対象としてフォーマットenitre LDAPResultの署名を含む[2]。
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制御（= 1.2.840.113549.6.0.2 OID）です。
SignedResult ::= CHOICE {
signature OCTET STRING }
The base OIDs are:
ベースOIDは、次のとおりです。
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
SignedOperation ::= CHOICE {
signbyServer NULL,
signatureIncluded OCTET STRING
}
Changes ::= SEQUENCE {
sequenceNumber [0] INTEGER (0 .. maxInt),
signedOperation [1] OCTET STRING }
DemandSignedResult ::= LDAPSigType
LDAPSigType ::= BOOLEAN
SignedResult ::= CHOICE {
signature OCTET STRING }
END
終わり
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クライアントは、彼らの検索時に連鎖した属性に含まれる署名を検証することが賢明です。署名者の証明書の発行認証局は、署名者の秘密鍵が危殆化されたか、または証明書がそうでない場合は失効しているかどうかを判断するために相談する必要があります。セキュリティの考慮事項は、このメモ中で議論されています。
[1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5", RFC 2315, March 1998.
[1] Kaliski、B.、 "PKCS 7：暗号メッセージ構文バージョン1-5"、RFC 2315、1998年3月。
[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メッセージ仕様"、RFC 2311、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マルチパートのセキュリティは：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、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）"、RFC 2251、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のContent-Type"、RFC 2425、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で使用するためのX.500（96）ユーザスキーマの概要"、RFC 2256、1997年12月。
[7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[7]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 2255、1997年12月。
[8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[8]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
Bruce Greenblatt San Jose, CA 95119 USA
ブルース・グリーンブラットサンノゼ、CA 95119 USA
Phone: +1-408-224-5349 EMail: bgreenblatt@directory-applications.com
電話：+ 1-408-224-5349 Eメール：bgreenblatt@directory-applications.com
Pat Richard Xcert Software, Inc. Suite 1001 - 701 W. Georgia Vancouver, BC CANADA V6G 1C9
パットリチャードXcertソフトウェア株式会社スイート1001から701 W.ジョージア州バンクーバー、BC CANADA V6G 1C9
EMail: patr@xcert.com
メールアドレス：patr@xcert.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。