RFC3923 日本語訳
3923 End-to-End Signing and Object Encryption for the ExtensibleMessaging and Presence Protocol (XMPP). P. Saint-Andre. October 2004. (Format: TXT=51828 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Saint-Andre Request for Comments: 3923 Jabber Software Foundation Category: Standards Track October 2004
コメントを求めるワーキンググループP.サンアンドレ要求をネットワークでつないでください: 3923年のおしゃべりソフトウェア財団カテゴリ: 標準化過程2004年10月
End-to-End Signing and Object Encryption for the
Extensible Messaging and Presence Protocol (XMPP)
終わりから終わりへの署名と広げることができるメッセージングと存在プロトコルのためのオブジェクト暗号化(XMPP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).
このメモはExtensible MessagingとPresenceプロトコル(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件. . . . . . . . . . . . . . . . . . . . . . . . 2 3。 メッセージ. . . . . . . . . . . . . . . . . . . . . 4 4を保証します。 存在. . . . . . . . . . . . . . . . . . . . . 9 5を保証します。 任意のXMPPがデータ. . . . . . . . . . . . . . . . 13 6であると機密保護します。 S/MIME世代と取り扱. . . . . . . . . . 15 7いのための規則。 受取人エラー処理. . . . . . . . . . . . . . . . . . 18 8。 ゲートウェイ. . . . . . . . . . 20 9つぼ: Communications Throughがietfであると機密保護してください: params:xml:xmpp-e2e Namespace. . . . . . . . . . . 21 10アプリケーション/xmpp+xmlメディアType.21 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . 22 12。 IANA問題. . . . . . . . . . . . . . . . . . . . 22 13。 つぼ:ietf:paramsのための参照. . . . . . . . . . . . . . . . . . . . . . . . . 23A.Schema: xml:ナノ秒:xmpp-e2e.26AuthorのAddress。 . . . . . . . . . . . . . . . . . . . . . . . . 26 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 27
Saint-Andre Standards Track [Page 1] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[1ページ]RFC3923XMPP
1. Introduction
1. 序論
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].
このメモはExtensible MessagingとPresenceプロトコル(XMPP)のために終わりから終わりへの署名とオブジェクト暗号化のメソッドを定義します。 (XMPPの情報に関して、[XMPP-CORE]と[XMPP-IM]を見てください。) ここに指定されたメソッドは、送付者が特定のユーザに向けられたどんな任意のXMPPスタンザも特定の受取人に送られたインスタントメッセージを署名する、そして/または、暗号化して、特定のユーザに向けられる存在情報を署名する、そして/または、暗号化して、署名する、そして/または、暗号化するのを可能にします。 その結果、このメモは、XMPP仕様が[IMP-REQS]で指定された必要条件を満たすのを助けます。
1.1. Terminology
1.1. 用語
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].
大文字で書かれたキーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14、RFC2119[用語]で説明されるように本書では解釈されることであるべきですか?
2. Requirements
2. 要件
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)
* プロトコルは受信されたメッセージ(NOTIFICATIONかINSTANT MESSAGE)が崩壊もしませんし、いじられてもいないという信用を確実にする手段を提供しなければなりません。 (セクション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)
* プロトコルは受信されたメッセージ(NOTIFICATIONかINSTANT MESSAGE)が敵によって記録されて、再生されていないという信用を確実にする手段を提供しなければなりません。 (セクション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)
* プロトコルは送信されたメッセージ(NOTIFICATIONかINSTANT MESSAGE)が確実に単に送付者が許すENTITIESで読み込み可能になるようにする手段を提供しなければなりません。 (セクション2.5.3)
Saint-Andre Standards Track [Page 2] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[2ページ]RFC3923XMPP
* 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がビーズPRESENCE INFORMATIONにSUBSCRIPTIONを設立すると、プロトコルはAに明らかにする内容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で送るように存在情報が正確であることを確かめるA手段を提供しなければなりません。(セクション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の内容を見ることができないのを確実にするA手段を提供しなければなりません。(セクション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が、いじらないことが起こったことを確かめることを意味するのを確実にするA手段を提供しなければなりません。 (セクション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. 定義されたメソッドはCommon PresenceとInstant Messaging(CPIM)がInstant MessagingとPresence(IMPP)作業部会によって発表された仕様であるとサポートする非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 Message Formatに従わなければなりません。
* 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 Presence情報Data Formatに従わなければなりません。
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]EnvelopeDataとの[SMIME]暗号化を使用しなければなりません。
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. 共同利用できる実装を可能にするために、送付と申し込みを受け付けるのはMandatoryから道具へのCryptographic Algorithms(セクション6.10)の下で指定されたアルゴリズムを実装しなければなりません。
Saint-Andre Standards Track [Page 3] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[3ページ]RFC3923XMPP
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]や[キャプス]のように。 しかしながら、このメモのための範囲の外にサービス発見プロトコルの定義があります。
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 groupchatメッセージの署名か暗号化([XMPP-IM]で言及されますがそれらが[IMP-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]での説明されるとしてのbroadcasted存在の署名か暗号化(ここに定義されたメソッドは指示された存在だけに適用されます)。
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]で説明されるときインスタントメッセージングと存在以外のアプリケーションの文脈の中に現れるコミュニケーションの署名か暗号化。
3. Securing Messages
3. メッセージを保証します。
3.1. Process for Securing Messages
3.1. メッセージを保証するには、処理してください。
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のRequirement3の指定されるとしての「メッセージ/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/>要素は以下のセクション9で、より完全に指定されるように'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間によって資格がある<メッセージ/>スタンザの<e2e/>子供に含まれたXML CDATA部([XML]のセクション2.7を見る)の中で結果として起こる署名しているそして/または、暗号化されたオブジェクトを提供してください。
3.2. Example of a Signed Message
3.2. 署名しているメッセージに関する例
The following example illustrates the defined steps for signing a message.
以下の例はメッセージに署名するための定義されたステップを例証します。
Saint-Andre Standards Track [Page 4] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[4ページ]RFC3923XMPP
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?
| 文書内容: メッセージ/CPIM| | From: ジュリエットキャピュレット<、不-、: juliet@example.com 、gt。| To: ロメオモンターグ<、不-、: romeo@example.net 、gt。| DateTime: 2003-12-09 T11:45:36.66Z| Subject: 嘆願| | 文書内容: テキスト/平野。 charset=utf-8| コンテントID: <1234567890@example.com>。| | いわれ芸術、なんじ、ロメオ--
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」オブジェクトを生成すると、送付エージェントはそれに署名するかもしれません。 結果は「複合か署名されること」のコンテントタイプを持っていて、2つの部品を含んでいる複合[SMIME]オブジェクト([MULTI]を見る)です: コンテントタイプが「メッセージ/CPIM」であるものとコンテントタイプが「pkcs7アプリケーション/署名」である別のもの。
Saint-Andre Standards Track [Page 5] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[5ページ]RFC3923XMPP
Example 2: Sender generates multipart/signed object:
例2: 送付者は複合の、または、署名しているオブジェクトを生成します:
| 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--
| コンテントタイプ: 複合か署名される。 次の境界=。 | micalg=sha1。 | プロトコル=pkcs7アプリケーション/署名| | --次へ| 文書内容: メッセージ/CPIM| | From: ジュリエットキャピュレット<、不-、: juliet@example.com 、gt。| To: ロメオモンターグ<、不-、: romeo@example.net 、gt。| DateTime: 2003-12-09 T23:45:36.66Z| Subject: 嘆願| | 文書内容: テキスト/平野。 charset=utf-8| コンテントID: <1234567890@example.com>。| | いわれ芸術、なんじ、ロメオ-- | --次へ| コンテントタイプ: pkcs7アプリケーション/署名| 満足している気質: 付属; =が必要とした取り扱い; \| ファイル名=smime.p7s| | [署名している身体の部分]| | --次--
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部で「複合か署名している」オブジェクトを包装します。(それは、XMPPメッセージスタンザとその子供要素は'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間によって資格があるとき含まれている<e2e/>要素に含まれています)。
Saint-Andre Standards Track [Page 6] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[6ページ]RFC3923XMPP
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>
| ' romeo@example.net/orchard 'タイプは'チャット'>と等しいこと'と等しい<メッセージ| <e2e xmlns='つぼ:ietf:params: xml:ナノ秒:xmpp-e2e'>'| <![CDATA[ | コンテントタイプ: 複合か署名される。 次の境界=。 | micalg=sha1。 | プロトコル=pkcs7アプリケーション/署名| | --次へ| 文書内容: メッセージ/CPIM| | From: ジュリエットキャピュレット<、不-、: juliet@example.com 、gt。| To: ロメオモンターグ<、不-、: romeo@example.net 、gt。| DateTime: 2003-12-09 T23:45:36.66Z| Subject: 嘆願| | 文書内容: テキスト/平野。 charset=utf-8| コンテントID: <1234567890@example.com>。| | いわれ芸術、なんじ、ロメオ-- | --次へ| コンテントタイプ: pkcs7アプリケーション/署名| 満足している気質: 付属; =が必要とした取り扱い; \| ファイル名=smime.p7s| | [署名している身体の部分]| | --次--| ]]>| </e2e>。| </メッセージ>。
3.3. Example of an Encrypted Message
3.3. 暗号化メッセージに関する例
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」オブジェクトを生成します。
Saint-Andre Standards Track [Page 7] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[7ページ]RFC3923XMPP
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?
| 文書内容: メッセージ/CPIM| | From: ジュリエットキャピュレット<、不-、: juliet@example.com 、gt。| To: ロメオモンターグ<、不-、: romeo@example.net 、gt。| DateTime: 2003-12-09 T11:45:36.66Z| Subject: 嘆願| | 文書内容: テキスト/平野。 charset=utf-8| コンテントID: <1234567890@example.com>。| | いわれ芸術、なんじ、ロメオ--
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==
| 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メッセージスタンザとその子供要素は'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間によって資格があるとき含まれている<e2e/>要素に含まれています)。
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>
| ' romeo@example.net/orchard 'タイプは'チャット'>と等しいこと'と等しい<メッセージ| <e2e xmlns='つぼ:ietf:params: xml:ナノ秒:xmpp-e2e'>'| <[CDATA[| U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ| /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9| Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL| Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a| + GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH|Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3|i08lEHzyll6htuEr59ZDAw=|]]!>。| </e2e>。| </メッセージ>。
Saint-Andre Standards Track [Page 8] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[8ページ]RFC3923XMPP
4. Securing Presence
4. 存在を保証します。
4.1. Process for Securing Presence Information
4.1. 存在が情報であると機密保護するには、処理してください。
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のRequirement3の指定されるとしての「アプリケーション/pidf+xml」オブジェクトを署名する、そして/または、暗号化してください。 3. <e2e/>要素は'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間によって資格がある<存在/>スタンザの<e2e/>子供に含まれたXML CDATA部([XML]のセクション2.7を見る)の中で結果として起こる署名しているそして/または、暗号化されたオブジェクトを提供してください。 <存在/>スタンザは'to'属性を含まなければなりません、すなわち、それが[XMPP-IM]で定義されるように指示された存在のインスタンスであるに違いありません。
4.2. Example of Signed Presence Information
4.2. 署名している存在情報に関する例
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>
| <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>| <存在xmlnsは「つぼ:ietf:params:xml:ナノ秒: pidf」と等しいです。| xmlns: 不-=、「つぼ:ietf:params:xml:ナノ秒: pidf:、不-、」| 実体=「pres: juliet@example.com 」、gt。| <tupleイド="hr0zny"| <状態>。| <の基本的な>開いている</基本的な>。| <、不-、: 遠くの不->、</、不-、: 不->。| </状態>。| <注意xml: langが等しい、「「>は部屋</注意>に退職した」アン| <タイムスタンプ>2003-12-09T23: 53:11.31</タイムスタンプ>。| </tuple>。| </存在>。
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]を見る)です: コンテントタイプが「アプリケーション/pidf+xml」であるものとコンテントタイプが「pkcs7アプリケーション/署名」である別のもの。
Saint-Andre Standards Track [Page 9] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[9ページ]RFC3923XMPP
Example 8: Sender generates multipart/signed object:
例8: 送付者は複合の、または、署名しているオブジェクトを生成します:
| 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--
| コンテントタイプ: 複合か署名される。 次の境界=。 | micalg=sha1。 | プロトコル=pkcs7アプリケーション/署名| | --次へ| 文書内容: アプリケーション/pidf+xml| コンテントID: <2345678901@example.com>。| | <xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>| <存在xmlnsは「つぼ:ietf:params:xml:ナノ秒: pidf」と等しいです。| xmlns: 不-=、「つぼ:ietf:params:xml:ナノ秒: pidf:、不-、」| 実体=「pres: juliet@example.com 」、gt。| <tupleイド=、「hr0zny">"| <状態>。| <の基本的な>開いている</基本的な>。| <、不-、: 遠くの不->、</、不-、: 不->。| </状態>。| <注意xml: langが等しい、「「>は部屋</注意>に退職した」アン| <タイムスタンプ>2003-12-09T23:53:11.31Z</タイムスタンプ>。| </tuple>。| </存在>。| --次へ| コンテントタイプ: pkcs7アプリケーション/署名| 満足している気質: 付属; =が必要とした取り扱い; \| ファイル名=smime.p7s| | [署名している身体の部分]| | --次--
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部で「複合か署名している」オブジェクトを包装します。(それは、XMPPメッセージスタンザとその子供要素は'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間によって資格があるとき含まれている<e2e/>要素に含まれています)。
Saint-Andre Standards Track [Page 10] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[10ページ]RFC3923XMPP
Example 9: Sender generates XMPP presence stanza:
例9: 送付者は、XMPP存在がスタンザであると生成します:
| <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>
| ' romeo@example.net/orchard 'と等しい<存在、gt。| <e2e xmlns='つぼ:ietf:params: xml:ナノ秒:xmpp-e2e'>'| <!CDATA| コンテントタイプ: 署名される複合/(境界=次)| micalg=sha1; | プロトコル=pkcs7アプリケーション/署名| | --次|文書内容:アプリケーション/pidf+xml| コンテントID; <2345678901@example; com>| | <のxmlバージョン=「=「UTF-8インチ?>| <存在xmlns=」つぼ:ietf:paramsをコード化する1インチ: xml:ナノ秒:pidf」 | xmlns: 不-=、「つぼ:ietf:params:xml:ナノ秒: pidf:、不-、」 | 実体=「pres: juliet@example.com 」、gt;、| <tupleイド=、「hr0zny、「>| <の基本的な>開いている</基本的な>| >| <状態<、不-、:、」; 遠くの不->、</、不-、: 不->| </状態>| <注意xml: langが等しい、「アン、「>は部屋</注意>に退きました| <タイムスタンプ>2003-12-09T23: 53:11」; 31Z</タイムスタンプ>| </tuple>| </存在>| --次| コンテントタイプ; pkcs7アプリケーション/署名| smime.p7s| | 署名している身体の部分| | | 満足している気質: 付属; =が必要とした取り扱い; \| ファイル名=--次-->。| </e2e>。| </存在>。
4.3. Example of Encrypted Presence Information
4.3. 暗号化された存在情報に関する例
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」オブジェクトを生成します。
Saint-Andre Standards Track [Page 11] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[11ページ]RFC3923XMPP
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>
| <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>| <存在xmlnsは「つぼ:ietf:params:xml:ナノ秒: pidf」と等しいです。| xmlns: 不-=、「つぼ:ietf:params:xml:ナノ秒: pidf:、不-、」| 実体=「pres: juliet@example.com 」、gt。| <tupleイド="hr0zny"| <状態>。| <の基本的な>開いている</基本的な>。| <、不-、: 遠くの不->、</、不-、: 不->。| </状態>。| <注意xml: langが等しい、「「>は部屋</注意>に退職した」アン| <タイムスタンプ>2003-12-09T23: 53:11.31</タイムスタンプ>。| </tuple>。| </存在>。
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=
| 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メッセージスタンザとその子供要素は'つぼ:ietf:params:xml:ナノ秒: xmpp-e2e'名前空間によって資格があるとき含まれている<e2e/>要素に含まれています)。
Saint-Andre Standards Track [Page 12] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[12ページ]RFC3923XMPP
Example 12: Sender generates XMPP presence stanza:
例12: 送付者は、XMPP存在がスタンザであると生成します:
| <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>
| ' romeo@example.net/orchard 'と等しい<存在、gt。| <e2e xmlns='つぼ:ietf:params: xml:ナノ秒: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>。| </存在>。
5. Securing Arbitrary XMPP Data
5. 任意のXMPPがデータであると機密保護します。
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には、<メッセージ/>と<存在/>に加えて三塁レベルスタンザタイプ(<iq/>)があります、3つのコアスタンザタイプの任意の子供要素の中に拡張XMLデータを含む能力と同様に。 したがって、できれば、そのようなデータを保証するのは望ましいでしょう。
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に指定されるとしてXMLメディアタイプで「アプリケーション/xmpp+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.)
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.)
Saint-Andre Standards Track [Page 13] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 13] RFC 3923 XMPP E2E October 2004
Example 13: Message stanza with extended data contained in "application/xmpp+xml" MIME type:
Example 13: Message stanza with extended data contained in "application/xmpp+xml" MIME type:
| <?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>
| <?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:
Example 14: Presence stanza with extended data contained in "application/xmpp+xml" MIME type:
| <?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>
| <?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:
Example 15: IQ stanza with extended data contained in "application/ xmpp+xml" MIME type:
| <?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>
| <?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>
Saint-Andre Standards Track [Page 14] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 14] RFC 3923 XMPP E2E October 2004
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.
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.
6. Rules for S/MIME Generation and Handling
6. Rules for S/MIME Generation and Handling
6.1. Certificate Enrollment
6.1. Certificate Enrollment
[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] 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.
6.2. Certificate Retrieval
6.2. Certificate Retrieval
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].
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].
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.
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.
6.3. Certificate Names
6.3. Certificate Names
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.
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.
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
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
Saint-Andre Standards Track [Page 15] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 15] RFC 3923 XMPP E2E October 2004
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.
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.
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.
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.
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.
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.
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].
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].
6.4. Transfer Encoding
6.4. Transfer Encoding
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".
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".
6.5. Order of Signing and Encrypting
6.5. Order of Signing and Encrypting
If a stanza is both signed and encrypted, it SHOULD be signed first, then encrypted.
If a stanza is both signed and encrypted, it SHOULD be signed first, then encrypted.
6.6. Inclusion of Certificates
6.6. Inclusion of Certificates
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.
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.
Saint-Andre Standards Track [Page 16] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 16] RFC 3923 XMPP E2E October 2004
6.7. Attachment and Checking of Signatures
6.7. Attachment and Checking of Signatures
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.
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.
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).
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).
6.8. Decryption
6.8. Decryption
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).
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).
6.9. Inclusion and Checking of Timestamps
6.9. Inclusion and Checking of Timestamps
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:
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:
o It MUST verify that the timestamp received is within five minutes
of the current time.
o It MUST verify that the timestamp received is within five minutes of the current time.
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 It SHOULD verify that the timestamp received is greater than any timestamp received in the last 10 minutes which passed the previous check.
Saint-Andre Standards Track [Page 17] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 17] RFC 3923 XMPP E2E October 2004
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 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).
6.10. Mandatory-to-Implement Cryptographic Algorithms
6.10. Mandatory-to-Implement Cryptographic Algorithms
All implementations MUST support the following algorithms. Implementations MAY support other algorithms as well.
All implementations MUST support the following algorithms. Implementations MAY support other algorithms as well.
For CMS SignedData:
For CMS SignedData:
o The SHA-1 message digest as specified in [CMS-ALG] section 2.1.
o The SHA-1 message digest as specified in [CMS-ALG] section 2.1.
o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as
specified in [CMS-ALG] section 3.2.
o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as specified in [CMS-ALG] section 3.2.
For CMS EnvelopedData:
For CMS EnvelopedData:
o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG]
section 4.2.1.
o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG] section 4.2.1.
o The AES-128 encryption algorithm in CBC mode, as specified in
[CMS-AES].
o The AES-128 encryption algorithm in CBC mode, as specified in [CMS-AES].
7. Recipient Error Handling
7. Recipient Error Handling
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:
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:
Case #1: The receiving application does not understand the protocol.
Case #1: The receiving application does not understand the protocol.
Case #2: The receiving application understands the protocol and is
able to decrypt the payload and verify the sender's signature.
Case #2: The receiving application understands the protocol and is able to decrypt the payload and verify the sender's signature.
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).
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).
Case #4: The receiving application understands the protocol and is
able to decrypt the payload but is unable to verify the sender's
signature.
Case #4: The receiving application understands the protocol and is able to decrypt the payload but is unable to verify the sender's signature.
Case #5: The receiving application understands the protocol but is
unable to decrypt the payload.
Case #5: The receiving application understands the protocol but is unable to decrypt the payload.
Saint-Andre Standards Track [Page 18] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 18] RFC 3923 XMPP E2E October 2004
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].
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].
In Case #2, the receiving application MUST NOT return a stanza error to the sender, since this is the success case.
In Case #2, the receiving application MUST NOT return a stanza error to the sender, since this is the success case.
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:
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:
Example 16: Recipient returns <not-acceptable/> error:
Example 16: Recipient returns <not-acceptable/> error:
<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>
<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:
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:
Example 17: Recipient returns <not-acceptable/> error:
Example 17: Recipient returns <not-acceptable/> error:
<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>
<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:
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:
Saint-Andre Standards Track [Page 19] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 19] RFC 3923 XMPP E2E October 2004
Example 18: Recipient returns <bad-request/> error:
Example 18: Recipient returns <bad-request/> error:
<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>
<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>
8. Secure Communications Through a Gateway
8. Secure Communications Through a Gateway
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:
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:
+-------------+ +-------------+ +------------+ | | | | | | | XMPP | | XMPP-CPIM | | Non-XMPP | | Service | <----> | Gateway | <----> | Service | | | | | | | +-------------+ +-------------+ +------------+
+-------------+ +-------------+ +------------+ | | | | | | | 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:
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:
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 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).
Saint-Andre Standards Track [Page 20] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 20] RFC 3923 XMPP E2E October 2004
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 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.
The wrapped S/MIME object MUST be immutable and MUST NOT be modified by an XMPP-CPIM gateway.
The wrapped S/MIME object MUST be immutable and MUST NOT be modified by an XMPP-CPIM gateway.
9. urn:ietf:params:xml:xmpp-e2e Namespace
9. urn:ietf:params:xml:xmpp-e2e Namespace
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:
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:
o [MSGFMT] for "Message/CPIM" o [PIDF] for "application/pidf+xml" o [XMPP-CORE] for "application/xmpp+xml"
o [MSGFMT] for "Message/CPIM" o [PIDF] for "application/pidf+xml" o [XMPP-CORE] for "application/xmpp+xml"
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].
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].
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]).
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]).
10. application/xmpp+xml Media Type
10. application/xmpp+xml Media Type
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].
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].
Saint-Andre Standards Track [Page 21] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 21] RFC 3923 XMPP E2E October 2004
11. Security Considerations
11. Security Considerations
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.
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.
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.
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.
12. IANA Considerations
12. IANA Considerations
12.1. XML Namespace Name for e2e Data in XMPP
12.1. XML Namespace Name for e2e Data in XMPP
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].)
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].)
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>
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>
12.2. Content-type Registration for "application/xmpp+xml"
12.2. Content-type Registration for "application/xmpp+xml"
To: ietf-types@iana.org
To: ietf-types@iana.org
Subject: Registration of MIME media type application/xmpp+xml
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 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.
Saint-Andre Standards Track [Page 22] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 22] RFC 3923 XMPP E2E October 2004
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
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
13. References
13. References
13.1. Normative References
13.1. Normative References
[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) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[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., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC
3859, August 2004.
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[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., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[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., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
Saint-Andre Standards Track [Page 23] RFC 3923 XMPP E2E October 2004
Saint-Andre Standards Track [Page 23] RFC 3923 XMPP E2E October 2004
[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., and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.
[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August
2004.
[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[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., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[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., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[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) Version 3.1 Message Specification", RFC 3851, July 2004.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[XML-MEDIA] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[XML-MEDIA] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and
Presence Protocol (XMPP): Core", RFC 3920, October
2004.
[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[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., "Extensible Messaging and Presence Protocol (XMPP) Instant Messaging and Presence", RFC 3921, October 2004.
Saint-Andre Standards Track [Page 24] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[24ページ]RFC3923XMPP
13.2. Informative References
13.2. 有益な参照
[CAPS] Hildebrand, J. and P. Saint-Andre, "Entity
Capabilities", JSF JEP 0115, August 2004.
[キャップ] ヒルデブラントとJ.とP.サンアンドレ、「実体能力」、JSF JEP0115、2004年8月。
[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797,
April 2000.
[CMC] マイアーズとM.とリュウとX.とSchaadとJ.とJ.ワインスタイン、「cmの上の証明書管理メッセージ」、RFC2797、2000年4月。
[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols", RFC
2510, March 1999.
[CMP] アダムスとC.とS.ファレル、「インターネットX.509公開鍵暗号基盤証明書管理プロトコル」、RFC2510、1999年3月。
[DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. Saint-
Andre, "Service Discovery", JSF JEP 0030, July 2004.
[ディスコ]のヒルデブラント、J.、ミラード、P.、Eatmon、R.、およびP.聖者2004年7月のアンドレ、「サービスディスカバリー」JSF JEP0030。
[MUC] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, June
2004.
[MUC] サンアンドレ、P.、「マルチユーザチャット」、JSF JEP0045、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] ロバの鳴き声とT.とパオリとJ.とSperberg-マックィーンとC.と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] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
Saint-Andre Standards Track [Page 25] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[25ページ]RFC3923XMPP
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
つぼ:ietf:paramsのための付録A.Schema: xml:ナノ秒:xmpp-e2e
The following XML schema is descriptive, not normative.
以下のXML図式は規範的であるのではなく、描写的です。
<?xml version='1.0' encoding='UTF-8'?>
<?xmlバージョン= '1.0'='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: ' http://www.w3.org/2001/XMLSchema '図式xmlns: xs=targetNamespaceは'つぼ:ietf:paramsと等しいです: xml:ナノ秒:xmpp-e2e'xmlns='つぼ:ietf:params: xml:ナノ秒:xmpp-e2e'elementFormDefault='は'>'に資格を与えました。
<xs:element name='e2e' type='xs:string'/>
<xs: 要素名前='e2e'タイプは'xs: ストリング'/>と等しいです。
<xs:element name='decryption-failed' type='empty'/>
<xs:element name='signature-unverified' type='empty'/>
<xs:element name='bad-timestamp' type='empty'/>
<xs: 要素名=の'悪いタイムスタンプの'タイプ='が空にする復号化で失敗した'タイプ='署名で非検証された'タイプ='が空にする空の'/><xs: 要素名=''/><xs: 要素名=''/>。
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
「<xs: simpleTypeは'空'の><xsと=を命名します: 制限ベースは'xsと等しいです: ></xs: '><xs: 列挙値=」/></xs: 制限simpleType>を結んでください'
</xs:schema>
</xs: 図式>。
Author's Address
作者のアドレス
Peter Saint-Andre Jabber Software Foundation
ピーターサンアンドレおしゃべりソフトウェア財団
EMail: stpeter@jabber.org
メール: stpeter@jabber.org
Saint-Andre Standards Track [Page 26] RFC 3923 XMPP E2E October 2004
E2004年10月の2Eのサンアンドレ標準化過程[26ページ]RFC3923XMPP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Saint-Andre Standards Track [Page 27]
サンアンドレ標準化過程[27ページ]
一覧
スポンサーリンク
