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)
        

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)インターネット協会(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
        
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].

このメモは、拡張メッセージングおよびプレゼンスプロトコル(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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" BCP 14、RFC 2119 [用語]で説明されるように解釈されるべきです。

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

それらは、[IMP-REQS]で定義した通りである。1.定義された方法は、最小のインスタントメッセージングおよびプレゼンスのための署名と暗号化の要件に対処しなければなりません。特に、この方法は、[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)
        

* 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メッセージングシステムとの相互運用性を有効にする必要があります。この要件の二つの帰結は、以下のとおりです。

       *  Prior to signing and/or encrypting, the format of an instant
          message MUST conform to the CPIM Message Format defined in
          [MSGFMT].
        

* 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:

前記方法は[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.アプリケーションが強制的に実装する暗号アルゴリズム(セクション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].

[XMPP-IM]に記載されたが、それらは[IMP-REQS]によって必要とされないので、その中に定義されていないXMPPグループチャットメッセージのO署名または暗号化。このようなメッセージは、最良[MUC]で指定されています。

o Signing or encryption of broadcasted presence as described in [XMPP-IM] (the methods defined herein apply to directed presence only).

[XMPP-IM]に記載されているように、O(本明細書で定義されたメソッドのみ向けプレゼンスに適用)署名又はブロードキャスト存在の暗号化。

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

[IMP-MODEL]と[IMP-REQS]に記載されているもののようなインスタントメッセージングとプレゼンス以外のアプリケーションのコンテキスト内で発生する通信のO署名または暗号化。

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].
【MSGFMT]で定義されるように1「メッセージ/ 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 />要素が修飾されている<メッセージ/>スタンザの<E2E />子に含まれる([XML]のセクション2.7を参照)XML CDATAセクション内で得られた署名されたおよび/または暗号化されたオブジェクトを提供します以下のセクション9でより完全に指定されている名前空間 ':IETF:のparams:XML::NS XMPP-E2E壷' で。

3.2. Example of a Signed Message
3.2. 署名されたメッセージの例

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?

|コンテンツ・タイプ:メッセージ/ CPIM | |投稿者:ジュリエットキャピュレット<イム:juliet@example.com> | To:ロミオモンタギュー<イム:romeo@example.net> |日時:2003-12-09T11:45:36.66Z |件名:懇願| |コンテンツタイプ:テキスト/平野。文字セット= UTF-8 |コンテンツID:<1234567890@example.com> | |芸術のthou、ロミオ何のために?

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」オブジェクトを生成した後、送信エージェントは、それに署名することができます。そのコンテンツタイプ「/ CPIMメッセージ」と、そのコンテンツタイプであり、別のあるもの:結果は「マルチパート/署名された」のコンテンツタイプを有し、2つの部分を含むマルチパート[SMIME]オブジェクト([MULTI]参照します) 「アプリケーション/ PKCS7署名」。

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

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.

送信エージェントは現在、XMPPメッセージスタンザの子要素として含まれ、それは「URNによって修飾された<E2E />要素に含まれるXML CDATAセクションにおいて、「マルチパート/署名された」オブジェクトをラップ:IETFを:のparams:XML:NS:XMPP-E2E」名前空間。

Example 3: Sender generates XMPP message stanza:

実施例3:Senderはスタンザ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>
        
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」オブジェクトを生成します。

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 | |投稿者:ジュリエットキャピュレット<イム:juliet@example.com> | To:ロミオモンタギュー<イム:romeo@example.net> |日時:2003-12-09T11:45:36.66Z |件名:懇願| |コンテンツタイプ:テキスト/平野。文字セット= UTF-8 |コンテンツID:<1234567890@example.com> | |芸術のthou、ロミオ何のために?

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.

IETF:paramsは:XML送信エージェントは、現在XMPPメッセージスタンザの子要素として含まれ、それは「URNによって修飾された<E2E />要素に含まれるXML CDATAセクションに暗号化されたオブジェクトをラップ:NS:XMPP-E2E」名前空間。

Example 6: Sender generates XMPP message stanza:

実施例6:Senderはスタンザ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>

| <メッセージto='romeo@example.net/orchard」タイプ= '' チャット> | <E2Eののxmlns = '壷: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> | </メッセージ>

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

[PIDF]で定義されるように1「アプリケーション/ PIDF + XML」オブジェクトを生成します。 2サイン及び/又は上記第2の要件3で指定されるように、「アプリケーション/ PIDF + XML」オブジェクトを暗号化します。 3. <E2E />要素が修飾されている<存在/>スタンザの<E2E />子に含まれる([XML]のセクション2.7を参照)XML CDATAセクション内で得られた署名されたおよび/または暗号化されたオブジェクトを提供します名前空間 ':IETF:のparams:XML::NS XMPP-E2E壷' で。 <存在/>スタンザは、[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:Senderが "アプリケーション/ 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 version = "1.0" エンコード= "UTF-8"?> | <プレゼンスのxmlns = "壷:IETF:のparams:XML:NS:PIDF" | xmlns:イム= "壷:IETF:のparams:XML:NS:PIDF:イム" |実体= "PRES:juliet@example.com"> | <タプルID = "hr0zny" | <状態> | <基本>開く</基本> | <IM:IM>離れて</ IM:IM> | </ステータス> | <メモのxml:LANG = "EN">室に引退した。</ノート> | <タイムスタンプ> 2003-12-09T23:53:11.31 </タイムスタンプ> | </タプル> | </プレゼンス>

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」でオブジェクトを生成した後、送信エージェントは、それに署名することができます。そのコンテンツタイプ「アプリケーション/ PIDF + xml」であり、そのもう一つのContent:結果が「マルチパート/署名された」のコンテンツタイプを有し、2つの部分を含むマルチパート[SMIME]オブジェクト([MULTI]参照します)タイプは、「アプリケーション/ PKCS7署名」です。

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&gt;
   |         <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.

送信エージェントは現在、XMPPメッセージスタンザの子要素として含まれ、それは「URNによって修飾された<E2E />要素に含まれるXML CDATAセクションにおいて、「マルチパート/署名された」オブジェクトをラップ:IETFを:のparams:XML:NS:XMPP-E2E」名前空間。

Example 9: Sender generates XMPP presence stanza:

実施例9:Senderは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>
        
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」オブジェクトを生成します。

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 version = "1.0" エンコード= "UTF-8"?> | <プレゼンスのxmlns = "壷:IETF:のparams:XML:NS:PIDF" | xmlns:イム= "壷:IETF:のparams:XML:NS:PIDF:イム" |実体= "PRES:juliet@example.com"> | <タプルID = "hr0zny" | <状態> | <基本>開く</基本> | <IM:IM>離れて</ IM:IM> | </ステータス> | <メモのxml:LANG = "EN">室に引退した。</ノート> | <タイムスタンプ> 2003-12-09T23:53:11.31 </タイムスタンプ> | </タプル> | </プレゼンス>

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 +英+ 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.

IETF:paramsは:XML送信エージェントは、現在XMPPメッセージスタンザの子要素として含まれ、それは「URNによって修飾された<E2E />要素に含まれるXML CDATAセクションに暗号化されたオブジェクトをラップ:NS:XMPP-E2E」名前空間。

Example 12: Sender generates XMPP presence stanza:

実施例12:Senderは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>

| <プレゼンスto='romeo@example.net/orchard '> | <E2Eののxmlns = '壷:IETF:のparams:XML:NS:XMPP-E2E'> | <![CDATA [| U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP + ziczu6zWZLFQxae6O5PP6iqpr2No | zOvBVMWvYeRAT0zd18hr6qsqKiGl / GZpAAbTvPtaBxeIykxsd1 + CX + U + iw0nEGCr | bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q +英+ 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は<メッセージ/>と<存在/>、ならびに3つのコアスタンザタイプの任意の子要素内の拡張XMLデータを含める機能に加えて、第三のベースレベルスタンザタイプ(<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タイプをカプセル化する能力を指定しているため、このメモで取られたアプローチは、「アプリケーション/ XMPP + xml」で以下のセクション10でより完全に指定されているという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.)

以下の例は、「アプリケーション/ XMPP + XML」MIMEタイプの構造を示す図です。 (注:これらの例で使用される「http://jabber.org/protocol/evil」名前空間がRFC 3514のインスタントメッセージング等価であると書かれたエイプリルフールのプロトコルに関連付けられている;それだけ拡張情報のインスタンスとして含まれますXMLスタンザに含まれており、機能的なXMPPの拡張として真剣に取られるべきではありません。)

Example 13: Message stanza with extended data contained in "application/xmpp+xml" MIME type:

実施例13:「アプリケーション/ 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>

| <?xmlのバージョン= '1.0' エンコーディング= 'UTF-8'?> | <XMPPのxmlns = 'おしゃべり:クライアント'> | <メッセージ| from='iago@example.com/pda」| to='emilia@example.com/cell '> | <身体> | |私は私が考えたものを彼に告げた、とこれ以上に告げません彼が見つけたものよりも、自分自身はaptと本当でした。 | </ BODY> | <悪のxmlns = 'のhttp://jabber.org/protocol/evil'/> | </メッセージ> | </ XMPP>

Example 14: Presence stanza with extended data contained in "application/xmpp+xml" MIME type:

実施例14:「アプリケーション/ 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>

| <?xmlのバージョン= '1.0' エンコーディング= 'UTF-8'?> | <XMPPのxmlns = 'おしゃべり:クライアント'> | <プレゼンスfrom='iago@example.com/pda '> | <ショー> DND </ショー> | <状態>扇動不和</ステータス> | <悪のxmlns = 'のhttp://jabber.org/protocol/evil'/> | </プレゼンス> | </ 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>

| <?xmlのバージョン= '1.0' エンコーディング= 'UTF-8'?> | <XMPPのxmlns = 'おしゃべり:クライアント'> | <IQタイプ= '結果' | from='iago@example.com/pda」| to='emilia@example.com/cell」| ID = 'evil1'> | <クエリのxmlns = 'ジャバー:IQ:バージョン'> | <名前> Stabber </名前> | <バージョン> 666 </バージョン> | <OS> FiendOS </ OS> | </問い合わせ> | <悪の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.

単に「/ CPIMメッセージ」と「アプリケーション/ PIDF + XML」オブジェクト、「アプリケーション/ XMPP + XML」オブジェクトと同様に署名されたおよび/または暗号化され、次いで、XML CDATAセクション内に封入される(XML【の2.7節を参照ネームスペース])<E2E />要素は、 ':IETF:paramsは:XML:NS XMPP-E2E URN' によって修飾された<存在/>スタンザの<E2E />子に含まれています。

6. Rules for S/MIME Generation and Handling
S / MIMEの生成および処理のための6のルール
6.1. Certificate Enrollment
6.1. 証明書の登録

[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]認証局から証明書を取得する方法を指定し、その代わりに、すべての送信エージェントがすでに証明書を持っていなければならないことを義務付けていません。 [CMP]と[CMC]:PKIXワーキンググループは、この記事の執筆時点では、証明書登録のための2つの別々の規格を作成しました。証明書の登録に使用する方法は、このメモの範囲外です。

6.2. Certificate Retrieval
6.2. 証明書の取得

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の展開のために、ユーザエージェントは自動的に署名したリターン・メッセージにその受信者の証明書を要求することを意図した受信者へのメッセージを生成する必要があります。受信と送信の薬剤はまた、彼らの後に検索を保証するようにユーザーに「ストアおよび保護」できるような方法で特派ための証明書をするためのメカニズムを提供する必要があります。

6.3. Certificate Names
6.3. 証明書の名前

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エンティティによって使用されるエンドエンティティ証明書は、有効なインスタントメッセージングとプレゼンスアドレスを含むべきです。 ([CPIM]で定義されるように、インスタントメッセージングのための)および「PRES:」URI:アドレスは両方として「IM」を指定するべきであるURI(存在について[CPP]で定義されるように、)。これらのURIの各々は、内部のsubjectAltNameタイプuniformResourceIdentifierでの別のGeneralNameエントリ(すなわち、二つの別々のエントリ)で指定する必要があります。サブジェクト識別名内の情報は無視されるべきです。

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

<:アドレスIM>各URIの形式でなければならない:「アドレス」部分は、[XMPP-CORE]で定義されるように(また、Jabberの識別子またはJIDとも呼ばれる)XMPPアドレスである<PRESアドレス>、付加とともに

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.

'イム:' または 'PRES:' URIスキーム。任意の有効な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の値は、属性「から」に含まれる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のリソース識別子部分が一致する目的のために無視されるべきであることを除いて、署名者の証明書で提供さ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オンxmppAddr」を用いて符号化されなければなりません。

6.4. Transfer Encoding
6.4. 転送エンコード

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で定義されるように)「バイナリ」でなければなりません。

6.5. Order of Signing and Encrypting
6.5. 署名と暗号化の順序

If a stanza is both signed and encrypted, it SHOULD be signed first, then encrypted.

スタンザは、両方の署名と暗号化されている場合、それはその後、最初に署名し暗号化する必要があります。

6.6. Inclusion of Certificates
6.6. 証明書のインクルージョン

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分ごとにスタンザ少なくとも一つの暗号化されたメッセージとともに送信者の証明書を含むべきです。アクティブ・メッセージング・セッションのコンテキスト外では、送信エージェントは、各暗号化メッセージスタンザと一緒に送信者の証明書を含むべきです。送信エージェントは暗号化された各プレゼンススタンザと一緒に送信者の証明書を含むかもしれません。しかし、送信エージェントは5分に1回以上の証明書を含めるべきではありません。

6.7. Attachment and Checking of Signatures
6.7. 添付ファイルや署名のチェック

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節)の下で説明するように送信者にスタンザエラーを返すことがあります。

6.8. Decryption
6.8. 復号化

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節)の下で説明するように送信者にスタンザエラーを返すことがあります。

6.9. Inclusion and Checking of Timestamps
6.9. インクルージョンとタイムスタンプのチェック

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]に従わなければならなくて、必要に応じて第二の画分を含む、オフセットなしで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節)で説明しました。

6.10. Mandatory-to-Implement Cryptographic Algorithms
6.10. 実装に必須の暗号化アルゴリズム

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.

[CMS-ALG]セクション2.1で指定されるように、O SHA-1メッセージダイジェスト。

o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as specified in [CMS-ALG] section 3.2.

SHA-1署名アルゴリズムとRSA(PKCS#1 V1.5)O、[CMS-ALG]セクション3.2で指定されるように。

For CMS EnvelopedData:

CMS EnvelopedDataの場合:

o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG] section 4.2.1.

O RSA(PKCS#1 V1.5)キー輸送、[CMS-ALG]セクション4.2.1で指定されるように。

o The AES-128 encryption algorithm in CBC mode, as specified in [CMS-AES].

[CMS-AES]で指定されるように、CBCモードのAES-128暗号化アルゴリズムO。

7. Recipient Error Handling
7.受信者のエラー処理

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つ、次のいずれか一方のみを実行しなければならない:(1)<E2E />拡張を無視し、(2)全体のスタンザを無視する、または(3)<サービス利用不可/>エラーを返します送信者に、[XMPP-CORE]に記載されているように。

In Case #2, the receiving application MUST NOT return a stanza error to the sender, since this is the success case.

これが成功する場合であるので、ケース#2では、受信側アプリケーションは、送信者にスタンザエラーを返してはなりません。

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では、受信側アプリケーションは、図示のように必要に応じてアプリケーション固有のエラー条件要素<不良タイムスタンプ/>によって補完、([XMPP-CORE]に記載されているように)送信者に<的に許容されない/>エラーを返すかもしれ未満:

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>

<メッセージfrom='romeo@example.net/orchard」TYPE = 'チャット'> <E2Eのxmlns = 'URN:IETF:paramsは:XML:NS:XMPP-E2E'> [ここでCDATAセクション</ E2E> <エラータイプ= '変更'> <的に許容されないのxmlns = 'URN:IETF:paramsは:XML:NS:XMPP-スタンザ' /> <不良タイムスタンプのxmlns = 'URN:IETF:paramsは:XML:XMPP-E2E' /> </エラー> </メッセージ>

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においては、受信側アプリケーションは、図示のように必要に応じてアプリケーション固有のエラー条件要素<未確認の署名/>によって補完、([XMPP-CORE]に記載されているように)送信者に<的に許容されない/>エラーを返すべきです未満:

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>

<メッセージfrom='romeo@example.net/orchard」TYPE = 'チャット'> <E2Eのxmlns = 'URN:IETF:paramsは:XML:NS:XMPP-E2E'> [ここでCDATAセクション</ E2E> <エラータイプ= '変更'> <的に許容されないのxmlns = 'URN:IETF:paramsは:XML:NS:XMPP-スタンザ' /> <未確認の署名のxmlns = 'URN:IETF:paramsは:XML:XMPP-E2E' /> </エラー> </メッセージ>

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:

ケース#5においては、受信側アプリケーションは、図示のように必要に応じてアプリケーション固有のエラー条件要素<復号化失敗/>によって補完、([XMPP-CORE]に記載されているように)送信者に<悪い要求/>エラーを返すべきです未満:

Example 18: Recipient returns <bad-request/> error:

実施例18:受信者は<悪い要求/>エラーを返します:

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

<メッセージfrom='romeo@example.net/orchard」TYPE = 'チャット'> <E2Eのxmlns = 'URN:IETF:paramsは:XML:NS:XMPP-E2E'> [ここでCDATAセクション</ E2E> <エラー> '変更' =タイプ<悪い要求のxmlns = '壷:IETF:のparams:XML:NS:XMPP-スタンザ' /> <復号化に失敗したのxmlns = '壷:IETF:のparams:XML:XMPP-E2E' /> </エラー> </メッセージ>

8. Secure Communications Through a Gateway
ゲートウェイを介して8セキュア通信

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] [IMP-REQS]に準拠して、インスタントメッセージングとプレゼンスサービス間の相互運用性のために使用される一般的なプロファイルを定義する。XMPPサービスと非XMPPとの間の通信の場合次のようにサービスを、私たちはこの関係を可視化することができます。

   +-------------+        +-------------+        +------------+
   |             |        |             |        |            |
   |    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).

ゲートウェイは、非XMPPサービス上のユーザ宛のXMPPサービスから保護されたXMPPメッセージまたは存在スタンザを受信すると、Oは、XMPP「ラッパー」を削除しなければならない(下のすべてと<E2E>を含むと</マルチS / MIMEオブジェクトを明らかにするために、E2E>タグ)は、次いで、ルートは、非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.

ゲートウェイはXMPPサービス上のユーザに宛てられた非XMPPサービスから保護された非XMPPインスタントメッセージまたはプレゼンス文書を受信すると、O、それは明らかにするために、非XMPP「ラッパー」(もしあれば)を除去しなければなりませんマルチS / MIMEオブジェクトは、ルートXMPPサービスへXMPPスタンザ次にXMPPメッセージまたは(<E2E>と</ E2E>タグを含む)の存在「ラッパー」のオブジェクトをラップし、そして。

The wrapped S/MIME object MUST be immutable and MUST NOT be modified by an XMPP-CPIM gateway.

ラップされたS / MIMEオブジェクトは不変でなければなりませんとXMPP - CPIMゲートウェイによって改変されてはいけません。

9. urn:ietf:params:xml:xmpp-e2e Namespace
9. URN:IETF:のparams:XML:XMPP-E2E名前空間

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' />要素は、XML CDATAセクションのラッパーである([XML]のセクション2.7を参照) "/ CPIMメッセージ" が含まれ、「アプリケーション/ PIDF + XML」、または "アプリケーション/ 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 "アプリケーション/ XMPP + XML" の[XMPP-CORE] O O [PIDF "アプリケーション/ PIDF + XML" の "メッセージ/ CPIM" の

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 />スタンザでありますこれらのスタンザタイプは[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]).

「:IETF:のparams:XML:NS:XMPP-E2E壷」名前空間は固有の意味を持っていないとのみ使用してプロトコルを指定し、バージョン管理は[PIDF]、[MSGFMT](カプセル化されたオブジェクトを定義するプロトコルの責任であることを考えます、および[XMPP-CORE])。

10. application/xmpp+xml Media Type
10.アプリケーション/ XMPP + xmlのメディアタイプ

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

"アプリケーション/ XMPP + xml" でメディアタイプが[XML-MEDIA]で指定されたガイドラインに準拠しています。このMIMEタイプのルート要素は<XMPP />で、ルート要素は、既定の名前空間 'の場合XMPPスタンザ・タイプのいずれか(すなわち、メッセージ、プレゼンス、またはIQ)に対応し、1つのみの子要素を含まなければなりませんジャバー:クライアント」または 『おしゃべり:サーバ』 [XMPP-CORE]で定義されています。このXMLメディアタイプの文字エンコーディングは、[XMPP-CORE]のセクション11.5に従って、UTF-8でなければなりません。

11. Security Considerations
11.セキュリティについての考慮事項

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.4を介して5.1)で与えられ、そしてXMPPに特に[XMPP-CORE(セクション12.6を介し12.1)で与えられます。また、[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仕様を実装するゲートウェイを介して固定されたインスタントメッセージおよびプレゼンス情報の交換をもたらすことができます。そのようなゲートウェイは、それがインタフェースれるインスタントメッセージングおよびプレゼンスプロトコルの最低限のセキュリティ要件に準拠しなければなりません。

12. IANA Considerations
12. IANAの考慮事項
12.1. XML Namespace Name for e2e Data in XMPP
12.1. XMPPでのE2EデータのXML名前空間名

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>

URI:URN:IETF:のparams:XML:NS:XMPP-E2E仕様:RFC 3923の説明:RFC 3923.登録者の接触によって定義されている。これは、拡張可能なメッセージングとプレゼンスプロトコルのための署名および暗号化されたコンテンツのXML名前空間名です:IESG、 <iesg@ietf.org>

12.2. Content-type Registration for "application/xmpp+xml"
12.2. 「アプリケーション/ XMPP + xml」でのコンテンツタイプの登録

To: ietf-types@iana.org

と: いえtfーtyぺs@いあな。おrg

Subject: Registration of MIME media type application/xmpp+xml

件名:MIMEメディアタイプ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メディアタイプ名:application MIMEサブタイプ名:XMPP + xmlの必須パラメータ:(なし)オプションのパラメータ:(文字セット)アプリケーション/ XMLのcharsetパラメータと同じRFC 3023に指定されています。 [XMPP-CORE]のセクション11.5あたりに、文字セットが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準拠のインスタントメッセージングとプレゼンスシステムを。追加情報:(なし)PersonとEメールアドレス詳細についての問い合わせ先:IESG、<iesg@ietf.org>意図している用法:COMMON著者/変更コントローラ:IETF、XMPPワーキンググループ

13. References
13.参考文献
13.1. Normative References
13.1. 引用規格

[CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.

[CERT] Ramsdell、B.、エド。、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張(S / MIME)バージョン3.1証明書の取り扱い"。

[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.、RFC 3565、2003年7月 "のAdvanced Encryption Standard(AES)暗号メッセージ構文(CMS)での暗号化アルゴリズムの使用"。

[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.とC.ニューマン、 "インターネット上の日付と時刻:タイムスタンプ"、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.、ドルナー、S.、およびK.ムーア、エド、 "インターネット・メッセージでプレゼンテーション情報を伝える:コンテンツ-Dispositionヘッダーフィールド"。、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]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、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日目、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、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.アトキンス、 "一般的なプレゼンスとインスタントメッセージング(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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "セキュリティマルチパートMIMEのために:マルチパート/署名およびマルチパート/暗号化"、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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット(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.、エド。、 "/セキュア多目的インターネットメール拡張(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.

[用語]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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]サンアンドレ、P.、エド、 "拡張メッセージングおよびプレゼンスプロトコル(XMPP):コア"。、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]サンアンドレ、P.、エド。、 "拡張メッセージングおよびプレゼンスプロトコル(XMPP)インスタントメッセージングとプレゼンス"、RFC 3921、2004年10月。

13.2. Informative References
13.2. 参考文献

[CAPS] Hildebrand, J. and P. Saint-Andre, "Entity Capabilities", JSF JEP 0115, August 2004.

[CAPS]ヒルデブラント、J.とP.サンアンドレ、 "エンティティの機能"、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]マイヤーズ、M.、劉、X.、Schaad、J.とJ.ワインスタイン、 "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]アダムス、C。およびS.ファレル、 "インターネット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]ヒルデブラント、J.、ミラード、P.、Eatmon、R.とP.サンアンドレ、 "サービス・ディスカバリー"、JSF JEP 0030、2004年7月。

[MUC] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, June 2004.

[MUC]サンアンドレ、P.、 "マルチユーザーチャット"、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]ブレイ、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] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e

骨壷のための付録A.スキーマ:IETF:のparams:XML:NS: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:スキーマの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 = '資格'>

<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:要素名= '復号に失敗した' TYPE = '空' /> <XS:要素名= '署名未確認' TYPE = '空' /> <XS:要素名= '悪いタイムスタンプ' TYPE =」空 '/>

<xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType>

<XS:単純名= '空'> <XS:制限基地= 'XS:文字列'> <XS:列挙値= '' /> </ XS:制限> </ XS:simpleTypeの>

</xs:schema>

</ XS:スキーマ>

Author's Address

著者のアドレス

Peter Saint-Andre Jabber Software Foundation

ピーターサンアンドレのJabberソフトウェア財団

EMail: stpeter@jabber.org

メールアドレス:stpeter@jabber.org

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004).

著作権(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.

この文書では、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.

この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR(もしあれば)後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。