[要約] RFC 3923は、XMPPプロトコルのためのエンドツーエンドの署名とオブジェクトの暗号化に関する仕様です。このRFCの目的は、XMPPメッセージングシステムのセキュリティを向上させ、メッセージの信頼性とプライバシーを確保することです。
Network Working Group P. Saint-Andre
Request for Comments: 3923 Jabber Software Foundation
Category: Standards Track October 2004
End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
拡張可能なメッセージと存在プロトコル（XMPP）のエンドツーエンドの署名とオブジェクト暗号化
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).
このメモは、拡張可能なメッセージングおよび存在プロトコル（XMPP）のエンドツーエンドの署名とオブジェクト暗号化の方法を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Securing Messages . . . . . . . . . . . . . . . . . . . . . 4
4. Securing Presence . . . . . . . . . . . . . . . . . . . . . 9
5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . 13
6. Rules for S/MIME Generation and Handling . . . . . . . . . . 15
7. Recipient Error Handling . . . . . . . . . . . . . . . . . . 18
8. Secure Communications Through a Gateway . . . . . . . . . . 20
9. urn:ietf:params:xml:xmpp-e2e Namespace . . . . . . . . . . . 21
10. application/xmpp+xml Media Type . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . 26
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). (For information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The method specified herein enables a sender to sign and/or encrypt an instant message sent to a specific recipient, sign and/or encrypt presence information that is directed to a specific user, and sign and/or encrypt any arbitrary XMPP stanza directed to a specific user. This memo thereby helps the XMPP specifications meet the requirements specified in [IMP-REQS].
このメモは、拡張可能なメッセージングおよび存在プロトコル（XMPP）のエンドツーエンドの署名とオブジェクト暗号化の方法を定義します。（XMPPの詳細については、[XMPP-Core]および[XMPP-IM]を参照してください。）ここで指定された方法により、送信者は特定の受信者に送信されたインスタントメッセージに署名および/または暗号化できます。特定のユーザーに向けられ、特定のユーザーに向けられた任意のXMPPスタンザに署名および/または暗号化されます。これにより、XMPP仕様が[Imp-Reqs]で指定された要件を満たすのに役立ちます。
This document inherits terminology defined in [CMS], [IMP-MODEL], [SMIME], and [XMPP-CORE].
このドキュメントは、[CMS]、[IMP-Model]、[SMIME]、および[XMPP-CORE]で定義された用語を継承します。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [TERMS].
大文字のキーワード「必須」、「必要」、「必須」、「「shall」、「shall」、「shall "、" should "、" nove "、" becommended "、" may "、および" optional "）BCP 14、RFC 2119 [用語]に記載されているとおりに解釈されます。
For the purposes of this memo, we stipulate the following requirements:
このメモの目的のために、次の要件を規定しています。
1. The method defined MUST address signing and encryption requirements for minimal instant messaging and presence, as those are defined in [IMP-REQS]. In particular, the method MUST address the following requirements, which are copied here verbatim from [IMP-REQS]:
1. 定義されたメソッドは、[IMP-REQS]で定義されているため、最小限のインスタントメッセージと存在の署名と暗号化の要件に対処する必要があります。特に、この方法は次の要件に対処する必要があります。これらの要件は、[Imp-reqs]から逐語的にコピーされます。
* The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been corrupted or tampered with. (Section 2.5.1)
* プロトコルは、受信したメッセージ（通知またはインスタントメッセージ）が破損または改ざんされていないという自信を確保するための手段を提供する必要があります。（セクション2.5.1）
* The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been recorded and played back by an adversary. (Section 2.5.2)
* プロトコルは、受信したメッセージ（通知またはインスタントメッセージ）が敵によって記録され、再生されていないという自信を確保するための手段を提供する必要があります。（セクション2.5.2）
* The protocol MUST provide means to ensure that a sent message (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that the sender allows. (Section 2.5.3)
* プロトコルは、送信されたメッセージ（通知またはインスタントメッセージ）が、送信者が許可するエンティティのみが読み取ることができることを確認するための手段を提供する必要があります。（セクション2.5.3）
* The protocol MUST allow any client to use the means to ensure non-corruption, non-playback, and privacy, but the protocol MUST NOT require that all clients use these means at all times. (Section 2.5.4)
* プロトコルは、いかなるクライアントも手段を使用して腐敗しない、非プレイバック、プライバシーを確保できるようにする必要がありますが、プロトコルはすべてのクライアントが常にこれらの手段を使用することを要求してはなりません。（セクション2.5.4）
* When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION, the protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A. (Section 5.1.4)
* AがBの存在情報のサブスクリプションを確立する場合、プロトコルは、Bの正確な受信をA.に開示することを選択する手段を提供する必要があります（セクション5.1.4）
* The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B. (Section 5.3.1)
* プロトコルは、Bから送信されたように、存在情報が正確であることを確認する手段を提供する必要があります（セクション5.3.1）
* The protocol MUST provide A means of ensuring that no other PRINCIPAL C can see the content of M. (Section 5.4.6)
* プロトコルは、他の主要なCがMの内容を見ることができないことを保証する手段を提供する必要があります（セクション5.4.6）
* The protocol MUST provide A means of ensuring that no other PRINCIPAL C can tamper with M, and B means to verify that no tampering has occurred. (Section 5.4.7)
* プロトコルは、他の主要なCがMを改ざんしないことを保証する手段を提供する必要があり、Bは改ざんが発生していないことを確認することを意味します。（セクション5.4.7）
2. The method defined MUST enable interoperability with non-XMPP messaging systems that support the Common Presence and Instant Messaging (CPIM) specifications published by the Instant Messaging and Presence (IMPP) Working Group. Two corollaries of this requirement are:
2. 定義されたメソッドは、インスタントメッセージングと存在（IMPP）ワーキンググループによって公開された共通の存在とインスタントメッセージング（CPIM）仕様をサポートする非XMPPメッセージングシステムとの相互運用性を有効にする必要があります。この要件の2つの結果は次のとおりです。
* Prior to signing and/or encrypting, the format of an instant message MUST conform to the CPIM Message Format defined in [MSGFMT].
* 署名および/または暗号化する前に、インスタントメッセージの形式は[MSGFMT]で定義されたCPIMメッセージ形式に準拠する必要があります。
* Prior to signing and/or encrypting, the format of presence information MUST conform to the CPP Presence Information Data Format defined in [PIDF].
* 署名および/または暗号化する前に、[PIDF]で定義されているCPPのプレゼンス情報データ形式に存在情報の形式に準拠する必要があります。
3. The method MUST follow the required procedures (including the specific algorithms) defined in [CPIM] and [CPP]. In particular, these documents specify:
3. この方法は、[CPIM]および[CPP]で定義されている必要な手順（特定のアルゴリズムを含む）に従う必要があります。特に、これらのドキュメントは次のように指定しています。
* Signing MUST use [SMIME] signatures with [CMS] SignedData.
* 署名は、[CMS] SignedDataを使用した[SMIME]署名を使用する必要があります。
* Encryption MUST use [SMIME] encryption with [CMS] EnvelopeData.
* 暗号化は、[CMS]包括的なデータを使用して[MIME]暗号化を使用する必要があります。
4. In order to enable interoperable implementations, sending and receiving applications MUST implement the algorithms specified under Mandatory-to-Implement Cryptographic Algorithms (Section 6.10).
4. 相互運用可能な実装を有効にするために、アプリケーションの送信と受信は、義務的な暗号化アルゴリズム（セクション6.10）で指定されたアルゴリズムを実装する必要があります。
We further stipulate that the following functionality is out of scope for this memo:
さらに、次の機能はこのメモの範囲外であると規定しています。
o Discovery of support for this protocol. An entity could discover whether another entity supports this protocol by (1) attempting to send signed or encrypted stanzas and receiving an error stanza ("technical" discovery) or a textual message in reply ("social" discovery) if the protocol is not supported, or (2) using a dedicated service discovery protocol, such as [DISCO] or [CAPS]. However, the definition of a service discovery protocol is out of scope for this memo.
o このプロトコルのサポートの発見。エンティティは、（1）署名型または暗号化されたスタンザを送信しようとし、エラースタンザ（「技術的な」発見）またはプロトコルがサポートされていない場合のエラースタンザ（「技術的な」発見）（「ソーシャル」発見）を受信しようとすることにより、別のエンティティがこのプロトコルをサポートするかどうかを発見できます。、または（2）[disco]や[caps]などの専用のサービスディスカバリープロトコルを使用します。ただし、サービスディスカバリープロトコルの定義は、このメモの範囲外です。
o Signing or encryption of XMPP groupchat messages, which are mentioned in [XMPP-IM] but not defined therein since they are not required by [IMP-REQS]; such messages are best specified in [MUC].
o XMPPグループチャットメッセージの署名または暗号化。[XMPP-IM]で言及されていますが、[inp-reqs]では要求されていないため、そこに定義されていません。このようなメッセージは、[MUC]で最もよく指定されています。
o Signing or encryption of broadcasted presence as described in [XMPP-IM] (the methods defined herein apply to directed presence only).
o [xmpp-im]で説明されているブロードキャスト存在の署名または暗号化（本明細書で定義されているメソッドは、指示された存在にのみ適用されます）。
o Signing or encryption of communications that occur within the context of applications other than instant messaging and presence as those are described in [IMP-MODEL] and [IMP-REQS].
o [IMP-Model]および[Imp-Reqs]で説明されているように、インスタントメッセージングと存在以外のアプリケーションのコンテキスト内で発生する通信の署名または暗号化。
In order to sign and/or encrypt a message, a sending agent MUST use the following procedure:
メッセージに署名および/または暗号化するには、送信エージェントが次の手順を使用する必要があります。
1. Generate a "Message/CPIM" object as defined in [MSGFMT].
1. [msgfmt]で定義されている「メッセージ/cpim」オブジェクトを生成します。
2. Sign and/or encrypt both the headers and content of the "Message/CPIM" object as specified in Requirement 3 of Section 2 above.
2. 上記のセクション2の要件3で指定されている「メッセージ/CPIM」オブジェクトのヘッダーとコンテンツの両方に署名および/または暗号化します。
3. Provide the resulting signed and/or encrypted object within an XML CDATA section (see Section 2.7 of [XML]) contained in an <e2e/> child of a <message/> stanza, where the <e2e/> element is qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as specified more fully in Section 9 below.
3. <メッセージ/>スタンザの<e2e/>子に含まれるXML CDATAセクション（[XML]のセクション2.7を参照）内で、結果の署名されたオブジェクトおよび/または暗号化されたオブジェクトを提供します。'urn：ietf：params：xml：ns：xmpp-e2e'名前空間は、以下のセクション9でより完全に指定されています。
The following example illustrates the defined steps for signing a message.
次の例は、メッセージに署名するための定義された手順を示しています。
First, the sending agent generates a "Message/CPIM" object in accordance with the rules and formats specified in [MSGFMT].
最初に、送信エージェントは、[MSGFMT]で指定されたルールと形式に従って「メッセージ/CPIM」オブジェクトを生成します。
Example 1: Sender generates "Message/CPIM" object:
例1：送信者は「メッセージ/cpim」オブジェクトを生成します：
| Content-type: Message/CPIM
|
| From: Juliet Capulet <im:juliet@example.com>
| To: Romeo Montague <im:romeo@example.net>
| DateTime: 2003-12-09T11:45:36.66Z
| Subject: Imploring
|
| Content-type: text/plain; charset=utf-8
| Content-ID: <1234567890@example.com>
|
| Wherefore art thou, Romeo?
Once the sending agent has generated the "Message/CPIM" object, the sending agent may sign it. The result is a multipart [SMIME] object (see [MULTI]) that has a Content-Type of "multipart/signed" and includes two parts: one whose Content-Type is "Message/CPIM" and another whose Content-Type is "application/pkcs7-signature".
送信エージェントが「メッセージ/CPIM」オブジェクトを生成すると、送信エージェントが署名することがあります。結果は、コンテンツタイプの「マルチパート/署名」のコンテンツタイプを備えたマルチパート[SMIME]オブジェクト（[Multi]を参照）で、2つの部分が含まれています。「Application/PKCS7-Signature」。
Example 2: Sender generates multipart/signed object:
例2：送信者はMultiPart/署名されたオブジェクトを生成します：
| Content-Type: multipart/signed; boundary=next;
| micalg=sha1;
| protocol=application/pkcs7-signature
|
| --next
| Content-type: Message/CPIM
|
| From: Juliet Capulet <im:juliet@example.com>
| To: Romeo Montague <im:romeo@example.net>
| DateTime: 2003-12-09T23:45:36.66Z
| Subject: Imploring
|
| Content-type: text/plain; charset=utf-8
| Content-ID: <1234567890@example.com>
|
| Wherefore art thou, Romeo?
| --next
| Content-Type: application/pkcs7-signature
| Content-Disposition: attachment;handling=required;\
| filename=smime.p7s
|
| [signed body part]
|
| --next--
The sending agent now wraps the "multipart/signed" object in an XML CDATA section, which is contained in an <e2e/> element that is included as a child element of the XMPP message stanza and that is qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
送信エージェントは、XML CDATAセクションに「MultiPart/Signed」オブジェクトをラップします。これには、XMPPメッセージスタンザの子要素として含まれ、 'urn：ietfが付属している<e2e/>要素に含まれています。：params：xml：ns：xmpp-e2e 'namespace。
Example 3: Sender generates XMPP message stanza:
例3：送信者はXMPPメッセージスタンザを生成します：
| <message to='romeo@example.net/orchard' type='chat'>
| <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
| <![CDATA[
| Content-Type: multipart/signed; boundary=next;
| micalg=sha1;
| protocol=application/pkcs7-signature
|
| --next
| Content-type: Message/CPIM
|
| From: Juliet Capulet <im:juliet@example.com>
| To: Romeo Montague <im:romeo@example.net>
| DateTime: 2003-12-09T23:45:36.66Z
| Subject: Imploring
|
| Content-type: text/plain; charset=utf-8
| Content-ID: <1234567890@example.com>
|
| Wherefore art thou, Romeo?
| --next
| Content-Type: application/pkcs7-signature
| Content-Disposition: attachment;handling=required;\
| filename=smime.p7s
|
| [signed body part]
|
| --next--
| ]]>
| </e2e>
| </message>
The following example illustrates the defined steps for encrypting a message.
次の例は、メッセージを暗号化するための定義された手順を示しています。
First, the sending agent generates a "Message/CPIM" object in accordance with the rules and formats specified in [MSGFMT].
最初に、送信エージェントは、[MSGFMT]で指定されたルールと形式に従って「メッセージ/CPIM」オブジェクトを生成します。
Example 4: Sender generates "Message/CPIM" object:
例4：送信者は「メッセージ/cpim」オブジェクトを生成します：
| Content-type: Message/CPIM
|
| From: Juliet Capulet <im:juliet@example.com>
| To: Romeo Montague <im:romeo@example.net>
| DateTime: 2003-12-09T11:45:36.66Z
| Subject: Imploring
|
| Content-type: text/plain; charset=utf-8
| Content-ID: <1234567890@example.com>
|
| Wherefore art thou, Romeo?
Once the sending agent has generated the "Message/CPIM" object, the sending agent may encrypt it.
送信エージェントが「メッセージ/CPIM」オブジェクトを生成すると、送信エージェントが暗号化できます。
Example 5: Sender generates encrypted object:
例5：送信者は暗号化されたオブジェクトを生成します：
| U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ
| /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9
| Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL
| Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a
| +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH
| Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3
| i08lEHzyll6htuEr59ZDAw==
The sending agent now wraps the encrypted object in an XML CDATA section, which is contained in an <e2e/> element that is included as a child element of the XMPP message stanza and that is qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
送信エージェントは、暗号化されたオブジェクトをXML CDATAセクションに包みます。これは、XMPPメッセージスタンザの子要素として含まれ、 'urn：ietf：params：xmlによって資格がある<e2e/>要素に含まれています。：ns：xmpp-e2e 'namespace。
Example 6: Sender generates XMPP message stanza:
例6：送信者はXMPPメッセージスタンザを生成します：
| <message to='romeo@example.net/orchard' type='chat'>
| <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
| <![CDATA[
| U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ
| /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9
| Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL
| Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a
| +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH
| Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3
| i08lEHzyll6htuEr59ZDAw==
| ]]>
| </e2e>
| </message>
In order to sign and/or encrypt presence information, a sending agent MUST use the following procedure:
存在情報に署名および/または暗号化するには、送信エージェントが次の手順を使用する必要があります。
1. Generate an "application/pidf+xml" object as defined in [PIDF]. 2. Sign and/or encrypt the "application/pidf+xml" object as specified in Requirement 3 of Section 2 above. 3. Provide the resulting signed and/or encrypted object within an XML CDATA section (see Section 2.7 of [XML]) contained in an <e2e/> child of a <presence/> stanza, where the <e2e/> element is qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. The <presence/> stanza MUST include a 'to' attribute, i.e., it must be an instance of directed presence as defined in [XMPP-IM].
1. [PIDF]で定義されている「アプリケーション/PIDF XML」オブジェクトを生成します。2.上記のセクション2の要件3で指定されているように、「アプリケーション/PIDF XML」オブジェクトに署名および/または暗号化します。3.結果の署名されたオブジェクトおよび/または暗号化されたオブジェクトをXML CDATAセクション内に提供します（[XML]のセクション2.7を参照）<E2E/>子の子に含まれる/> Stanzaの子。'urn：ietf：params：xml：ns：xmpp-e2e' namespaceによる。<encless/> stanzaには、[xmpp-im]で定義されているように、「to」属性を含める必要があります。
The following example illustrates the defined steps for signing presence information.
次の例は、存在情報に署名するための定義された手順を示しています。
First, the sending agent generates an "application/pidf+xml" object in accordance with the rules and formats specified in [PIDF].
まず、送信エージェントは、[PIDF]で指定されたルールと形式に従って「アプリケーション/PIDF XML」オブジェクトを生成します。
Example 7: Sender generates "application/pidf+xml" object:
例7：送信者は「アプリケーション/PIDF XML」オブジェクトを生成します：
| <?xml version="1.0" encoding="UTF-8"?>
| <presence xmlns="urn:ietf:params:xml:ns:pidf"
| xmlns:im="urn:ietf:params:xml:ns:pidf:im"
| entity="pres:juliet@example.com">
| <tuple id="hr0zny"
| <status>
| <basic>open</basic>
| <im:im>away</im:im>
| </status>
| <note xml:lang="en">retired to the chamber</note>
| <timestamp>2003-12-09T23:53:11.31</timestamp>
| </tuple>
| </presence>
Once the sending agent has generated the "application/pidf+xml" object, the sending agent may sign it. The result is a multipart [SMIME] object (see [MULTI]) that has a Content-Type of "multipart/signed" and includes two parts: one whose Content-Type is "application/pidf+xml" and another whose Content-Type is "application/pkcs7-signature".
送信エージェントが「アプリケーション/PIDF XML」オブジェクトを生成すると、送信エージェントが署名することがあります。結果は、コンテンツタイプの「マルチパート/署名」を持ち、2つの部分を含むマルチパート[SMIME]オブジェクト（[Multi]を参照）です。「Application/PKCS7-Signature」です。
Example 8: Sender generates multipart/signed object:
例8：送信者はMultiPart/署名されたオブジェクトを生成します：
| Content-Type: multipart/signed; boundary=next;
| micalg=sha1;
| protocol=application/pkcs7-signature
|
| --next
| Content-type: application/pidf+xml
| Content-ID: <2345678901@example.com>
|
| <xml version="1.0" encoding="UTF-8"?>
| <presence xmlns="urn:ietf:params:xml:ns:pidf"
| xmlns:im="urn:ietf:params:xml:ns:pidf:im"
| entity="pres:juliet@example.com">
| <tuple id="hr0zny">
| <status>
| <basic>open</basic>
| <im:im>away</im:im>
| </status>
| <note xml:lang="en">retired to the chamber</note>
| <timestamp>2003-12-09T23:53:11.31Z</timestamp>
| </tuple>
| </presence>
| --next
| Content-Type: application/pkcs7-signature
| Content-Disposition: attachment;handling=required;\
| filename=smime.p7s
|
| [signed body part]
|
| --next--
The sending agent now wraps the "multipart/signed" object in an XML CDATA section, which is contained in an <e2e/> element that is included as a child element of the XMPP message stanza and that is qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
送信エージェントは、XML CDATAセクションに「MultiPart/Signed」オブジェクトをラップします。これには、XMPPメッセージスタンザの子要素として含まれ、 'urn：ietfが付属している<e2e/>要素に含まれています。：params：xml：ns：xmpp-e2e 'namespace。
Example 9: Sender generates XMPP presence stanza:
例9：送信者はXMPPの存在感を生成しますStanza：
| <presence to='romeo@example.net/orchard'>
| <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
| <![CDATA[
| Content-Type: multipart/signed; boundary=next;
| micalg=sha1;
| protocol=application/pkcs7-signature
|
| --next
| Content-type: application/pidf+xml
| Content-ID: <2345678901@example.com>
|
| <xml version="1.0" encoding="UTF-8"?>
| <presence xmlns="urn:ietf:params:xml:ns:pidf"
| xmlns:im="urn:ietf:params:xml:ns:pidf:im"
| entity="pres:juliet@example.com">
| <tuple id="hr0zny">
| <status>
| <basic>open</basic>
| <im:im>away</im:im>
| </status>
| <note xml:lang="en">retired to the chamber</note>
| <timestamp>2003-12-09T23:53:11.31Z</timestamp>
| </tuple>
| </presence>
| --next
| Content-Type: application/pkcs7-signature
| Content-Disposition: attachment;handling=required;\
| filename=smime.p7s
|
| [signed body part]
|
| --next--
| ]]>
| </e2e>
| </presence>
The following example illustrates the defined steps for encrypting presence information.
次の例は、存在情報を暗号化するための定義された手順を示しています。
First, the sending agent generates an "application/pidf+xml" object in accordance with the rules and formats specified in [PIDF].
まず、送信エージェントは、[PIDF]で指定されたルールと形式に従って「アプリケーション/PIDF XML」オブジェクトを生成します。
Example 10: Sender generates "application/pidf+xml" object:
例10：送信者は「アプリケーション/PIDF XML」オブジェクトを生成します：
| <?xml version="1.0" encoding="UTF-8"?>
| <presence xmlns="urn:ietf:params:xml:ns:pidf"
| xmlns:im="urn:ietf:params:xml:ns:pidf:im"
| entity="pres:juliet@example.com">
| <tuple id="hr0zny"
| <status>
| <basic>open</basic>
| <im:im>away</im:im>
| </status>
| <note xml:lang="en">retired to the chamber</note>
| <timestamp>2003-12-09T23:53:11.31</timestamp>
| </tuple>
| </presence>
Once the sending agent has generated the "application/pidf+xml" object, the sending agent may encrypt it.
送信エージェントが「アプリケーション/PIDF XML」オブジェクトを生成すると、送信エージェントが暗号化できます。
Example 11: Sender generates encrypted object:
例11：送信者は暗号化されたオブジェクトを生成します。
| U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP+ziczu6zWZLFQxae6O5PP6iqpr2No
| zOvBVMWvYeRAT0zd18hr6qsqKiGl/GZpAAbTvPtaBxeIykxsd1+CX+U+iw0nEGCr
| bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q+uk+O3jrqX4byL
| GBlKThbzKidxz32ObojPEEwfFiM/yUeqYUP1OcJpUmeQ8lcXhD6tcx+m2MAyYYLP
| boKQxpLknxRnbM8T/voedlnFLbbDu69mOlxDPbr1mHZd3hDsyFudb1fb4rI3Kw0K
| Nq+3udr2IkysviJDgQo+xGIQUG/5sED/mAaPRlj4f/JtTzvT4EaQTawv69ntXfKV
| MCr9KdIMMdjdJzOJkYLoAhNVrcZn5tw8WsJGwuKuhYb/SShy7InzOapPaPAl7/Mm
| PHj7zj3NZ6EEIweDOuAwWlIG/dT506tci27+EW7JnXwMPnFMkF+6a7tr/0Y+iiej
| woJxUIBqCOgX+U7srHpK2NYtNTZ7UQp2V0yEx1JV8+Y=
The sending agent now wraps the encrypted object in an XML CDATA section, which is contained in an <e2e/> element that is included as a child element of the XMPP message stanza and that is qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
送信エージェントは、暗号化されたオブジェクトをXML CDATAセクションに包みます。これは、XMPPメッセージスタンザの子要素として含まれ、 'urn：ietf：params：xmlによって資格がある<e2e/>要素に含まれています。：ns：xmpp-e2e 'namespace。
Example 12: Sender generates XMPP presence stanza:
例12：送信者はXMPPの存在感を生成しますStanza：
| <presence to='romeo@example.net/orchard'>
| <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
| <![CDATA[
| U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP+ziczu6zWZLFQxae6O5PP6iqpr2No
| zOvBVMWvYeRAT0zd18hr6qsqKiGl/GZpAAbTvPtaBxeIykxsd1+CX+U+iw0nEGCr
| bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q+uk+O3jrqX4byL
| GBlKThbzKidxz32ObojPEEwfFiM/yUeqYUP1OcJpUmeQ8lcXhD6tcx+m2MAyYYLP
| boKQxpLknxRnbM8T/voedlnFLbbDu69mOlxDPbr1mHZd3hDsyFudb1fb4rI3Kw0K
| Nq+3udr2IkysviJDgQo+xGIQUG/5sED/mAaPRlj4f/JtTzvT4EaQTawv69ntXfKV
| MCr9KdIMMdjdJzOJkYLoAhNVrcZn5tw8WsJGwuKuhYb/SShy7InzOapPaPAl7/Mm
| PHj7zj3NZ6EEIweDOuAwWlIG/dT506tci27+EW7JnXwMPnFMkF+6a7tr/0Y+iiej
| woJxUIBqCOgX+U7srHpK2NYtNTZ7UQp2V0yEx1JV8+Y=
| ]]>
| </e2e>
| </presence>
The foregoing sections of this memo describe how to secure "least common denominator" messaging and presence data of the kind that can be directly translated into the MSGFMT or PIDF formats. However, XMPP possesses a third base-level stanza type (<iq/>) in addition to <message/> and <presence/>, as well as the ability to include extended XML data within arbitrary child elements of the three core stanza types. Therefore, it would be desirable to secure such data if possible.
このメモの前述のセクションでは、MSGFMTまたはPIDF形式に直接変換できる種類の「最も一般的な分母」メッセージと存在データを保護する方法について説明します。ただし、XMPPは、<メッセージ/>および<プレゼンス/>に加えて、3 baseレベルのスタンザタイプ（<IQ/>）を所有しています。。したがって、可能であれば、そのようなデータを保護することが望ましいでしょう。
Because [MSGFMT] specifies the ability to encapsulate any MIME type, the approach taken in this memo is to include arbitrary XMPP data in an XML media type named "application/xmpp+xml" as specified more fully in Section 10 below.
[MSGFMT]はMIMEタイプをカプセル化する機能を指定するため、このメモで取得したアプローチは、以下のセクション10でより完全に指定されているように、「Application/XMPP XML」という名前のXMLメディアタイプに任意のXMPPデータを含めることです。
The following examples illustrate the structure of the "application/xmpp+xml" MIME type. (Note: The 'http://jabber.org/protocol/evil' namespace used in these examples is associated with an April Fool's protocol written to be the instant messaging equivalent of RFC 3514; it is included only as an instance of extended information included in an XML stanza and should not be taken seriously as a functional XMPP extension.) Example 13: Message stanza with extended data contained in "application/xmpp+xml" MIME type:
次の例は、「アプリケーション/XMPP XML」MIMEタイプの構造を示しています。（注：「http://jabber.org/protocol/evil 'これらの例で使用されている名前空間は、RFC 3514に相当するインスタントメッセージングと書かれたエイプリルフールのプロトコルに関連付けられています。これは、拡張情報のインスタンスとしてのみ含まれていますXML Stanzaに含まれており、機能的なXMPP拡張機能として真剣に受け止められるべきではありません。）例13：「Application/XMPP XML」MIMEタイプに含まれる拡張データを備えたメッセージスタンザ：
| <?xml version='1.0' encoding='UTF-8'?>
| <xmpp xmlns='jabber:client'>
| <message
| from='iago@example.com/pda'
| to='emilia@example.com/cell'>
| <body>
| I told him what I thought, and told no more
| Than what he found himself was apt and true.
| </body>
| <evil xmlns='http://jabber.org/protocol/evil'/>
| </message>
| </xmpp>
Example 14: Presence stanza with extended data contained in "application/xmpp+xml" MIME type:
例14：「Application/XMPP XML」MIMEタイプに含まれる拡張データを備えた存在スタンザ：
| <?xml version='1.0' encoding='UTF-8'?>
| <xmpp xmlns='jabber:client'>
| <presence from='iago@example.com/pda'>
| <show>dnd</show>
| <status>Fomenting dissension</status>
| <evil xmlns='http://jabber.org/protocol/evil'/>
| </presence>
| </xmpp>
Example 15: IQ stanza with extended data contained in "application/ xmpp+xml" MIME type:
例15：「アプリケーション/ XMPP XML」MIMEタイプに含まれる拡張データを備えたIQスタンザ：
| <?xml version='1.0' encoding='UTF-8'?>
| <xmpp xmlns='jabber:client'>
| <iq type='result'
| from='iago@example.com/pda'
| to='emilia@example.com/cell'
| id='evil1'>
| <query xmlns='jabber:iq:version'>
| <name>Stabber</name>
| <version>666</version>
| <os>FiendOS</os>
| </query>
| <evil xmlns='http://jabber.org/protocol/evil'/>
| </iq>
| </xmpp>
Just as with the "Message/CPIM" and "application/pidf+xml" objects,
the "application/xmpp+xml" object would be signed and/or encrypted,
then encapsulated within an XML CDATA section (see Section 2.7 of
[XML]) contained in an <e2e/> child of a <presence/> stanza, where
the <e2e/> element is qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
[SMIME] does not specify how to obtain a certificate from a certificate authority, but instead mandates that every sending agent must already have a certificate. The PKIX Working Group has, at the time of this writing, produced two separate standards for certificate enrollment: [CMP] and [CMC]. Which method to use for certificate enrollment is outside the scope of this memo.
[SMIME]は、証明書当局から証明書を取得する方法を指定するのではなく、代わりにすべての送信エージェントがすでに証明書を持っている必要があることを義務付けています。PKIXワーキンググループは、この執筆時点で、証明書の登録に関する2つの個別の基準を作成しています。[CMP]と[CMC]。証明書の登録に使用する方法は、このメモの範囲外です。
A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This memo does not address how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certification issues are covered in [CERT].
受信エージェントは、デジタルエンベロープの受信者の証明書にアクセスするために、いくつかの証明書取得メカニズムを提供する必要があります。このメモは、S/MIMEエージェントが証明書をどのように処理するかについてはなく、証明書が検証または拒否された後に行うことだけです。S/MIME認定の問題は[CERT]でカバーされています。
However, at a minimum, for initial S/MIME deployment, a user agent SHOULD automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
ただし、少なくとも、最初のS/MIME展開の場合、ユーザーエージェントは、署名された返品メッセージで受信者の証明書を要求する意図した受信者に自動的にメッセージを生成する必要があります。また、エージェントを受信および送信する必要は、ユーザーがそのような方法で特派員の証明書を「保存および保護する」ことを可能にして、後の検索を保証するメカニズムを提供する必要があります。
End-entity certificates used by XMPP entities in the context of this memo SHOULD contain a valid instant messaging and presence address. The address SHOULD be specified as both an 'im:' URI (for instant messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as defined in [CPP]); each of these URIs SHOULD be specified in a separate GeneralName entry of type uniformResourceIdentifier inside the subjectAltName (i.e., two separate entries). Information in the subject distinguished name SHOULD be ignored.
このメモのコンテキストでXMPPエンティティが使用するエンドエンティティ証明書には、有効なインスタントメッセージングと存在アドレスを含める必要があります。アドレスは、 'im：' uri（[cpim]で定義されているインスタントメッセージング用）と 'pres：' uri（[cpp]で定義されている存在用）の両方として指定する必要があります。これらの各uriは、sumberaltaltname内のタイプの均一なresourceidentidifierの個別の一般名で指定する必要があります（つまり、2つの別々のエントリ）。主題の著名な名前の情報は無視する必要があります。
Each URI MUST be of the form <im:address> or <pres:address>, where the "address" portion is an XMPP address (also referred to as a Jabber Identifier or JID) as defined in [XMPP-CORE], prepended with the 'im:' or 'pres:' URI scheme. The address SHOULD be of the form <node@domain> (i.e., a "bare JID"), although any valid JID form MAY be used.
各uriはフォームでなければなりません「im：」または 'pres：' uriスキームで。アドレスは<Node@Domain>（つまり、「Bare Jid」）のフォームである必要がありますが、有効なJIDフォームは使用できます。
The value of the JID contained in the XMPP 'from' attribute MUST match a JID provided in the signer's certificate, with the exception that the resource identifier portion of the JID contained in the 'from' attribute SHOULD be ignored for matching purposes.
「属性」からXMPP 'に含まれるJIDの値は、「From」属性に含まれるJIDのリソース識別子部分が一致する目的で無視する必要があることを除いて、署名者の証明書に記載されているJIDと一致する必要があります。
Receiving agents MUST check that the sending JID matches a JID provided in the signer's certificate, with the exception that the resource identifier portion of the JID contained in the 'from' attribute SHOULD be ignored for matching purposes. A receiving agent SHOULD provide some explicit alternate processing of the stanza if this comparison fails, which may be to display a message informing the recipient of the addresses in the certificate or other certificate details.
受信エージェントは、送信jidが署名者の証明書に記載されているJIDと一致することを確認する必要があります。受信エージェントは、この比較が失敗した場合、スタンザの明示的な代替処理を提供する必要があります。これは、証明書またはその他の証明書の詳細のアドレスを受信者に通知するメッセージを表示する場合があります。
The subject alternative name extension is used in S/MIME as the preferred means to convey the instant messaging and presence address that corresponds to the entity for this certificate. Any XMPP address present in the certificate MUST be encoded using the ASN.1 Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of [XMPP-CORE].
件名の代替名拡張は、この証明書のエンティティに対応するインスタントメッセージングと存在アドレスを伝えるための優先手段として、S/MIMEで使用されます。証明書に存在するxmppアドレスは、[xmpp-core]のセクション5.1.1で指定されているように、asn.1オブジェクト識別子「id-on-xmppaddr」を使用してエンコードする必要があります。
Because it is expected that XMPP applications will not interface with older 7-bit systems, the transfer encoding (as defined in Section 3.1.2 of [SMIME]) MUST be "binary".
XMPPアプリケーションは古い7ビットシステムとインターフェイスしないことが予想されるため、転送エンコーディング（[SMIME]のセクション3.1.2で定義されている）は「バイナリ」でなければなりません。
If a stanza is both signed and encrypted, it SHOULD be signed first, then encrypted.
スタンザが署名され、暗号化されている場合、最初に署名してから暗号化する必要があります。
If the sender and recipient are involved in an active messaging session over a period of time, the sending agent SHOULD include the sender's certificate along with at least one encrypted message stanza every five minutes. Outside the context of an active messaging session, the sending agent SHOULD include the sender's certificate along with each encrypted message stanza. A sending agent MAY include the sender's certificate along with each encrypted presence stanza. However, a sending agent SHOULD NOT include a certificate more than once every five minutes.
送信者と受信者が一定期間にわたってアクティブなメッセージングセッションに関与している場合、送信エージェントには、5分ごとに少なくとも1つの暗号化されたメッセージスタンザとともに送信者の証明書を含める必要があります。アクティブなメッセージングセッションのコンテキストの外で、送信エージェントには、暗号化された各メッセージスタンザとともに送信者の証明書を含める必要があります。送信エージェントには、暗号化された各存在スタンザとともに、送信者の証明書を含めることができます。ただし、送信エージェントには、5分ごとに1回以上証明書を含めるべきではありません。
Sending agents SHOULD attach a signature to each encrypted XML stanza. If a signature is attached, a Content-Disposition header field (as defined in [DISP]) SHOULD be included to specify how the signature is to be handled by the receiving application.
送信エージェントは、暗号化された各XMLスタンザに署名を添付する必要があります。署名が添付されている場合、受信アプリケーションによって署名がどのように処理されるかを指定するために、コンテンツディスポジションヘッダーフィールド（[Disp]で定義されています）を含める必要があります。
If the receiving agent determines that the signature attached to an encrypted XML stanza is invalid, it SHOULD NOT present the stanza to the intended recipient (human or application), SHOULD provide some explicit alternate processing of the stanza (which may be to display a message informing the recipient that the attached signature is invalid), and MAY return a stanza error to the sender as described under Recipient Error Handling (Section 7).
受信エージェントが、暗号化されたXMLスタンザに添付された署名が無効であると判断した場合、スタンザを意図した受信者（人間またはアプリケーション）に提示しないでください。添付の署名が無効であることを受信者に通知し、受信者エラー処理（セクション7）で説明されているように、Stanzaエラーを送信者に返すことがあります。
If the receiving agent is unable to decrypt the encrypted XML stanza, it SHOULD NOT present the stanza to the intended recipient (human or application), SHOULD provide some explicit alternate processing of the stanza (which may be to display a message informing the recipient that it has received a stanza that cannot be decrypted), and MAY return a stanza error to the sender as described under Recipient Error Handling (Section 7).
受信エージェントが暗号化されたXMLスタンザを復号化できない場合、スタンザを意図した受信者（人間またはアプリケーション）に提示しないでください。スタンザの明示的な代替処理を提供する必要があります（これは、受信者に通知するメッセージを表示する可能性があります。復号化できないスタンザを受け取り、受信者エラー処理（セクション7）で説明されているように、スタンザエラーを送信者に返すことがあります。
Timestamps are included in "Message/CPIM" and "application/pidf+xml" objects to help prevent replay attacks. All timestamps MUST conform to [DATETIME] and be presented as UTC with no offset, including fractions of a second as appropriate. Absent a local adjustment to the sending agent's perceived time or the underlying clock time, the sending agent MUST ensure that the timestamps it sends to the receiver increase monotonically (if necessary by incrementing the seconds fraction in the timestamp if the clock returns the same time for multiple requests). The following rules apply to the receiving application:
タイムスタンプは、リプレイ攻撃を防ぐのに役立つ「メッセージ/CPIM」および「アプリケーション/PIDF XML」オブジェクトに含まれています。すべてのタイムスタンプは[DateTime]に準拠し、必要に応じて1秒の画分を含むオフセットのないUTCとして提示する必要があります。送信中のエージェントの知覚時間または基礎となるクロック時間に対するローカル調整がなければ、送信エージェントは、レシーバーに送信するタイムスタンプが単調に増加することを確認する必要があります（必要に応じて、クロックが同じ時間を返す場合、タイムスタンプの秒分数を増加させることで必要に応じて複数のリクエスト）。以下のルールは、受信アプリケーションに適用されます。
o It MUST verify that the timestamp received is within five minutes of the current time.
o 受け取ったタイムスタンプが現在の5分以内であることを確認する必要があります。
o It SHOULD verify that the timestamp received is greater than any timestamp received in the last 10 minutes which passed the previous check.
o 受け取ったタイムスタンプが、前のチェックに合格した過去10分間に受け取ったどのタイムスタンプよりも大きいことを確認する必要があります。
o If any of the foregoing checks fails, the timestamp SHOULD be presented to the receiving entity (human or application) marked as "old timestamp", "future timestamp", or "decreasing timestamp", and the receiving entity MAY return a stanza error to the sender as described under Recipient Error Handling (Section 7).
o 前述のチェックのいずれかが失敗した場合、タイムスタンプは、「古いタイムスタンプ」、「将来のタイムスタンプ」、または「タイムスタンプの減少」としてマークされた受信エンティティ（人間またはアプリケーション）に提示する必要があり、受信エンティティはスタンザエラーを返す場合があります。受信者エラー処理の下で説明されている送信者（セクション7）。
All implementations MUST support the following algorithms. Implementations MAY support other algorithms as well.
すべての実装は、次のアルゴリズムをサポートする必要があります。実装は、他のアルゴリズムもサポートする場合があります。
For CMS SignedData:
CMS SignedDataの場合：
o The SHA-1 message digest as specified in [CMS-ALG] section 2.1.
o [CMS-Alg]セクション2.1で指定されているSHA-1メッセージダイジェスト。
o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as specified in [CMS-ALG] section 3.2.
o [CMS-Alg]セクション3.2で指定されているSHA-1シグネチャアルゴリズムを備えたRSA（PKCS＃1 V1.5）。
For CMS EnvelopedData:
CMS EnvelopedDataの場合：
o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG] section 4.2.1.
o [CMS-ALG]セクション4.2.1で指定されているRSA（PKCS＃1 V1.5）キートランスポート。
o The AES-128 encryption algorithm in CBC mode, as specified in [CMS-AES].
o [CMS-AES]で指定されているように、CBCモードのAES-128暗号化アルゴリズム。
When an XMPP entity receives an XML stanza containing data that is signed and/or encrypted using the protocol described herein, several scenarios are possible:
XMPPエンティティが、本明細書に記載されているプロトコルを使用して署名および/または暗号化されたデータを含むXMLスタンザを受信すると、いくつかのシナリオが可能です。
Case #1: The receiving application does not understand the protocol.
ケース＃1：受信アプリケーションはプロトコルを理解していません。
Case #2: The receiving application understands the protocol and is able to decrypt the payload and verify the sender's signature.
ケース＃2：受信アプリケーションはプロトコルを理解し、ペイロードを復号化し、送信者の署名を確認することができます。
Case #3: The receiving application understands the protocol and is able to decrypt the payload and verify the sender's signature, but the timestamps fail the checks specified above under Checking of Timestamps (Section 6.9).
ケース＃3：受信アプリケーションはプロトコルを理解し、ペイロードを復号化して送信者の署名を検証することができますが、タイムスタンプはタイムスタンプのチェックで上記のチェックに失敗します（セクション6.9）。
Case #4: The receiving application understands the protocol and is able to decrypt the payload but is unable to verify the sender's signature.
ケース＃4：受信アプリケーションはプロトコルを理解し、ペイロードを復号化することができますが、送信者の署名を確認することはできません。
Case #5: The receiving application understands the protocol but is unable to decrypt the payload.
ケース＃5：受信アプリケーションはプロトコルを理解していますが、ペイロードを復号化することはできません。
In Case #1, the receiving application MUST do one and only one of the following: (1) ignore the <e2e/> extension, (2) ignore the entire stanza, or (3) return a <service-unavailable/> error to the sender, as described in [XMPP-CORE].
ケース＃1では、受信アプリケーションは次のいずれかを実行する必要があります。（1）<e2e/>拡張機能を無視する、（2）スタンザ全体を無視する、または（3）<service-unavailable/>エラーを返します[xmpp-core]で説明されているように、送信者に。
In Case #2, the receiving application MUST NOT return a stanza error to the sender, since this is the success case.
ケース＃2では、受信アプリケーションはサクセスケースであるため、Stanzaエラーを送信者に返してはなりません。
In Case #3, the receiving application MAY return a <not-acceptable/> error to the sender (as described in [XMPP-CORE]), optionally supplemented by an application-specific error condition element <bad-timestamp/> as shown below:
ケース＃3では、受信アプリケーションは、表示されるように、アプリケーション固有のエラー条件要素<bad-timestamp/>でオプションで補足された、[[xmpp-core]に記載されている）送信者に<acceptable/>エラーを送信する場合があります。下に：
Example 16: Recipient returns <not-acceptable/> error:
例16：受信者が返される<容認できない/>エラー：
<message from='romeo@example.net/orchard' type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
[CDATA section here]
</e2e>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-timestamp xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
In Case #4, the receiving application SHOULD return a <not-acceptable/> error to the sender (as described in [XMPP-CORE]), optionally supplemented by an application-specific error condition element <unverified-signature/> as shown below:
ケース＃4では、受信アプリケーションは、表示されるように、アプリケーション固有のエラー条件要素<unverified-signature/>によってオプションで補足された、[xmpp-core]で説明されているように、<acceptable/>エラーを送信者に返す必要があります。下に：
Example 17: Recipient returns <not-acceptable/> error:
例17：受信者が返される<容認できない/>エラー：
<message from='romeo@example.net/orchard' type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
[CDATA section here]
</e2e>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unverified-signature xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
In Case #5, the receiving application SHOULD return a <bad-request/> error to the sender (as described in [XMPP-CORE]), optionally supplemented by an application-specific error condition element <decryption-failed/> as shown below: Example 18: Recipient returns <bad-request/> error:
ケース＃5では、受信アプリケーションは<bad-request/>エラーを送信者に返す必要があります（[xmpp-core]で説明されているように）。以下：例18：受信者が返される<bad-request/>エラー：
<message from='romeo@example.net/orchard' type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
[CDATA section here]
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<decryption-failed xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
A common method for achieving interoperability between two disparate services is through the use of a "gateway" that interprets the protocols of each service and translates them into the protocols of the other. The CPIM specifications (specifically [MSGFMT] and [PIDF] define the common profiles to be used for interoperability between instant messaging and presence services that comply with [IMP-REQS]. In the case of communications between an XMPP service and a non-XMPP service, we can visualize this relationship as follows:
2つの異なるサービス間で相互運用性を達成するための一般的な方法は、各サービスのプロトコルを解釈して他のプロトコルに変換する「ゲートウェイ」を使用することです。CPIM仕様（具体的には[MSGFMT]および[PIDF]は、XMPPサービスと非XMPP間の通信の場合、インスタントメッセージングと[Imp-Reqs]に準拠する存在サービスとの相互運用性に使用される共通プロファイルを定義します。サービス、次のようにこの関係を視覚化できます。
+-------------+ +-------------+ +------------+
| | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service |
| | | | | |
+-------------+ +-------------+ +------------+
The end-to-end encryption method defined herein enables the exchange of encrypted and/or signed instant messages and presence through an XMPP-CPIM gateway. In particular:
ここで定義されているエンドツーエンドの暗号化方法は、XMPP-CPIMゲートウェイを介して暗号化および/または署名されたインスタントメッセージの交換と存在感を可能にします。特に：
o When a gateway receives a secured XMPP message or presence stanza from the XMPP service that is addressed to a user on the non-XMPP service, it MUST remove the XMPP "wrapper" (everything down to and including the <e2e> and </e2e> tags) in order to reveal the multipart S/MIME object, then route the object to the non-XMPP service (first wrapping it in the protocol used by the non-XMPP service if necessary).
o ゲートウェイがXMPPサービス以外のユーザーにアドレス指定されたXMPPサービスからセキュリティで保護されたXMPPメッセージまたはプレゼンススタンザを受信した場合、XMPP「ラッパー」（<E2E>および</e2eを含むすべてのものを削除する必要があります。> Tags）マルチパートS/MIMEオブジェクトを公開するには、オブジェクトを非XMPPサービスにルーティングします（最初に非XMPPサービスで使用されているプロトコルで包みます。必要に応じて）。
o When a gateway receives a secured non-XMPP instant message or presence document from the non-XMPP service that is addressed to a user on the XMPP service, it MUST remove the non-XMPP "wrapper" (if any) in order to reveal the multipart S/MIME object, wrap the object in an XMPP message or presence "wrapper" (including the <e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP service.
o ゲートウェイがXMPPサービスのユーザーにアドレス指定された非XMPPサービスから安全な非XMPPインスタントメッセージまたはプレゼンスドキュメントを受信した場合、XMPP以外の「ラッパー」（もしあれば）を削除する必要があります。MultiPart S/MIMEオブジェクト、オブジェクトをXMPPメッセージまたは存在「ラッパー」（<E2E>および</e2e>タグを含む）にラップし、XMPPスタンザをXMPPサービスにルーティングします。
The wrapped S/MIME object MUST be immutable and MUST NOT be modified by an XMPP-CPIM gateway.
ラップされたS/MIMEオブジェクトは不変である必要があり、XMPP-CPIMゲートウェイで変更しないでください。
The <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/> element is a wrapper for an XML CDATA section (see Section 2.7 of [XML]) that contains a "Message/CPIM", "application/pidf+xml", or "application/xmpp+xml" object. Thus the 'urn:ietf:params:xml:xmpp-e2e' namespace has no inherent semantics, and the semantics of the encapsulated object are defined by one of the following specifications:
<e2e xmlns = 'urn：ietf：params：xml：ns：xmpp-e2e'/>要素は、「メッセージ/cpim」、「」を含むxml cdataセクション（[xml]のセクション2.7を参照）のラッパーです。Application/PIDF XML "、または「Application/XMPP XML」オブジェクト。したがって、「urn：ietf：params：xml：xmpp-e2e」名前空間には固有のセマンティクスがなく、カプセル化されたオブジェクトのセマンティクスは、次の仕様のいずれかによって定義されます。
o [MSGFMT] for "Message/CPIM" o [PIDF] for "application/pidf+xml" o [XMPP-CORE] for "application/xmpp+xml"
o [msgfmt] for "application/pidf xml" o [xmpp-core] for "application/xmpp xml"の "message/cpim" o [pidf]
Although the "application/xmpp+xml" media type is specified in this document, the <xmpp/> element is simply a wrapper for a <message/>, <presence/>, or <iq/> stanza, where the semantics of those stanza types are specified in [XMPP-CORE].
「アプリケーション/xmpp xml」メディアタイプはこのドキュメントで指定されていますが、<xmpp/>要素は、<メッセージ/>、<存在/>、または<iq/> stanzaのラッパーです。スタンザタイプは[xmpp-core]で指定されています。
Given that the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace has no inherent semantics and specifies a using protocol only, versioning is the responsibility of the protocols that define the encapsulated objects ([MSGFMT], [PIDF], and [XMPP-CORE]).
'urn：ietf：params：xml：ns：xmpp-e2e' namespaceには固有のセマンティクスがなく、プロトコルのみを指定していることを考えると、バージョンはカプセル化されたオブジェクトを定義するプロトコルの責任です（[msgfmt]、[pidf]、および[xmpp-core]）。
The "application/xmpp+xml" media type adheres to the guidelines specified in [XML-MEDIA]. The root element for this MIME type is <xmpp/>, and the root element MUST contain one and only one child element, corresponding to one of the XMPP stanza types (i.e., message, presence, or iq) if the default namespace is 'jabber:client' or 'jabber:server' as defined in [XMPP-CORE]. The character encoding for this XML media type MUST be UTF-8, in accordance with Section 11.5 of [XMPP-CORE].
[XML-MEDIA]で指定されたガイドラインには、「アプリケーション/XMPP XML」メディアタイプが付着します。このMIMEタイプのルート要素は<XMPP/>であり、ルート要素には、デフォルトの名前空間がある場合、XMPPスタンザタイプ（つまり、メッセージ、存在、またはIQ）の1つに対応する1つの子要素のみを含む必要があります。Jabber：クライアント 'または「jabber：server」[xmpp-core]で定義されています。[XMPP-CORE]のセクション11.5に従って、このXMLメディアタイプのエンコードをエンコードする文字はUTF-8でなければなりません。
This entire memo discusses security. Detailed security considerations for instant messaging and presence protocols are given in [IMP-REQS] (Sections 5.1 through 5.4), and for XMPP in particular are given in [XMPP-CORE] (Sections 12.1 through 12.6). In addition, all of the security considerations specified in [XML-MEDIA] apply to the "application/xmpp+xml" media type.
このメモ全体でセキュリティについて説明します。インスタントメッセージングと存在プロトコルの詳細なセキュリティ上の考慮事項は、[IMP-REQS]（セクション5.1〜5.4）に記載されており、特にXMPPについては[XMPP-CORE]（セクション12.1〜12.6）に示されています。さらに、[xml-media]で指定されたすべてのセキュリティに関する考慮事項は、「アプリケーション/xmpp xml」メディアタイプに適用されます。
The end-to-end security method defined here MAY result in exchanging secured instant messages and presence information through a gateway that implements the CPIM specifications. Such a gateway MUST be compliant with the minimum security requirements of the instant messaging and presence protocols with which it interfaces.
ここで定義されているエンドツーエンドのセキュリティ方法は、CPIM仕様を実装するゲートウェイを介して、保護されたインスタントメッセージと存在情報を交換する可能性があります。このようなゲートウェイは、インスタントメッセージングおよび存在プロトコルの最小セキュリティ要件に準拠している必要があります。
A URN sub-namespace of signed and encrypted content for the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
拡張可能なメッセージと存在プロトコル（XMPP）の署名付きおよび暗号化されたコンテンツのurnサブネームスペースは、次のように定義されます。（この名前空間名は、[xml-reg]で定義されている形式に準拠しています。）
URI: urn:ietf:params:xml:ns:xmpp-e2e
Specification: RFC 3923
Description: This is an XML namespace name of signed and encrypted
content for the Extensible Messaging and Presence Protocol as
defined by RFC 3923.
Registrant Contact: IESG, <iesg@ietf.org>
To: ietf-types@iana.org
宛先：ietf-types@iana.org
Subject: Registration of MIME media type application/xmpp+xml
MIME media type name: application MIME subtype name: xmpp+xml Required parameters: (none) Optional parameters: (charset) Same as charset parameter of application/xml as specified in RFC 3023; per Section 11.5 of [XMPP-CORE], the charset must be UTF-8. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023; per Section 11.5 of [XMPP-CORE], the encoding must be UTF-8.
MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：XMPP XML必須パラメーター：（なし）オプションパラメーター：（炭隔）RFC 3023で指定されているアプリケーション/XMLのCHARSETパラメーターと同じ。[xmpp-core]のセクション11.5ごとに、charsetはutf-8でなければなりません。考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ。[XMPP-CORE]のセクション11.5ごとに、エンコードはUTF-8でなければなりません。
Security considerations: All of the security considerations specified in RFC 3023 and [XMPP-CORE] apply to this XML media type. Refer to Section 11 of RFC 3923. Interoperability considerations: (none) Specification: RFC 3923 Applications which use this media type: XMPP-compliant instant messaging and presence systems. Additional information: (none) Person and email address to contact for further information: IESG, <iesg@ietf.org> Intended usage: COMMON Author/Change controller: IETF, XMPP Working Group
セキュリティ上の考慮事項：RFC 3023および[XMPP-CORE]で指定されたセキュリティ上の考慮事項はすべて、このXMLメディアタイプに適用されます。RFC 3923のセクション11を参照してください。相互運用性の考慮事項：（なし）仕様：このメディアタイプを使用するRFC 3923アプリケーション：XMPP準拠のインスタントメッセージングおよびプレゼンスシステム。追加情報:(なし）連絡先の人とメールアドレス詳細については、IESG、<IESG@IETF.ORG>意図された使用法：Common Auther/Change Controller：IETF、XMPPワーキンググループグループ
[CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[CERT] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMS-AES] Schaad、J。、「暗号化メッセージの構文（CMS）の高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMS-Alg] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[CPP]ピーターソン、J。、「存在の共通プロファイル（CPP）」、RFC 3859、2004年8月。
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[DateTime] Klyne、G。and C. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[DISP] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[Disp] Troost、R.、Dorner、S。、およびK. Moore、ed。、「インターネットメッセージでのプレゼンテーション情報の伝達：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[Imp-Model] Day、M.、Rosenberg、J。、およびH. Sugano、「存在感とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.
[Imp-reqs] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「インスタントメッセージング/存在プロトコル要件」、RFC 2779、2000年2月。
[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[MSGFMT] Klyne、G。およびD. Atkins、「Common Expention and Instantメッセージング（CPIM）：メッセージ形式」、RFC 3862、2004年8月。
[MULTI] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[Multi] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/Encrypted」、RFC 1847、1995年10月。
[PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[PIDF] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「Presence Information Data Format（PIDF）」、RFC 3863、2004年8月。
[SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[Smime] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[用語] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[XML-MEDIA] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[XML-Media]ムラタ、M。、セントローラン、S。およびD.コーン、「XMLメディアタイプ」、RFC 3023、2001年1月。
[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-Core] Saint-Andre、P.、ed。、「Extensibleメッセージングとプレゼンスプロトコル（XMPP）：Core」、RFC 3920、2004年10月。
[XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP) Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM] Saint-Andre、P.、ed。、「拡張可能なメッセージと存在プロトコル（XMPP）インスタントメッセージングと存在」、RFC 3921、2004年10月。
[CAPS] Hildebrand, J. and P. Saint-Andre, "Entity Capabilities", JSF JEP 0115, August 2004.
[Caps] Hildebrand、J。and P. Saint-Andre、「Entity機能」、JSF JEP 0115、2004年8月。
[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[CMC] Myers、M.、Liu、X.、Schaad、J。、およびJ. Weinstein、「CMS上の証明書管理メッセージ」、RFC 2797、2000年4月。
[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.
[CMP] Adams、C。およびS. Farrell、「インターネットX.509公開キーインフラストラクチャ証明書管理プロトコル」、RFC 2510、1999年3月。
[DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. Saint-Andre, "Service Discovery", JSF JEP 0030, July 2004.
[Disco] Hildebrand、J.、Millard、P.、Eatmon、R。およびP. Saint-Andre、「Service Discovery」、JSF JEP 0030、2004年7月。
[MUC] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, June 2004.
[MUC] Saint-Andre、P。、「Multi-User Chat」、JSF JEP 0045、2004年6月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (3rd ed)", W3C REC-xml, February 2004, <http://www.w3.org/TR/REC-xml>.
[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。and E. Maler、「拡張可能なマークアップ言語（XML）1.0（第3版）」、W3C Rec-XML、2004年2月、<http：//www.w3.org/tr/rec-xml>。
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[XML-Reg] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
The following XML schema is descriptive, not normative.
次のXMLスキーマは記述的であり、規範ではありません。
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e'
elementFormDefault='qualified'>
<xs:element name='e2e' type='xs:string'/>
<xs:element name='decryption-failed' type='empty'/>
<xs:element name='signature-unverified' type='empty'/>
<xs:element name='bad-timestamp' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Author's Address
著者の連絡先
Peter Saint-Andre Jabber Software Foundation
Peter Saint-Andre Jabber Software Foundation
EMail: stpeter@jabber.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。