Network Working Group                                     P. Saint-Andre
Request for Comments: 3923                    Jabber Software Foundation
Category: Standards Track                                   October 2004
        
Network Working Group                                     P. Saint-Andre
Request for Comments: 3923                    Jabber Software Foundation
Category: Standards Track                                   October 2004
        

End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

可扩展消息和状态协议(XMPP)的端到端签名和对象加密

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2004).

版权所有(C)互联网协会(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 . . . . . . . . . . . . . . . . . . . . . . . .   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].

本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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]:

1. 定义的方法必须满足[IMP-REQS]中定义的最低即时消息和状态的签名和加密要求。特别是,该方法必须满足以下要求,此处逐字复制自[IMP-REQS]:

* The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been corrupted or tampered with. (Section 2.5.1)

* 协议必须提供确保收到的消息(通知或即时消息)未被破坏或篡改的方法。(第2.5.1节)

* The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been recorded and played back by an adversary. (Section 2.5.2)

* 协议必须提供手段,确保收到的消息(通知或即时消息)未被对手记录和播放。(第2.5.2节)

* The protocol MUST provide means to ensure that a sent message (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that the sender allows. (Section 2.5.3)

* 协议必须提供确保发送的消息(通知或即时消息)只能由发送方允许的实体读取的方法。(第2.5.3节)

* The protocol MUST allow any client to use the means to ensure non-corruption, non-playback, and privacy, but the protocol MUST NOT require that all clients use these means at all times. (Section 2.5.4)

* 协议必须允许任何客户端使用这些方法来确保无损坏、无回放和隐私,但协议不得要求所有客户端在任何时候都使用这些方法。(第2.5.4节)

* When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION, the protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A. (Section 5.1.4)

* 当A订阅了B的状态信息时,协议必须提供一种方法来验证B选择披露给A的内容的准确接收。(第5.1.4节)

* The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B. (Section 5.3.1)

* 协议必须提供验证B发送的状态信息是否准确的方法。(第5.3.1节)

* The protocol MUST provide A means of ensuring that no other PRINCIPAL C can see the content of M. (Section 5.4.6)

* 协议必须提供一种方法,确保其他主体C不能看到M的内容。(第5.4.6节)

* The protocol MUST provide A means of ensuring that no other PRINCIPAL C can tamper with M, and B means to verify that no tampering has occurred. (Section 5.4.7)

* 协议必须提供一种方法来确保没有其他主体C可以篡改M,而B则提供一种方法来验证没有发生篡改。(第5.4.7节)

2. The method defined MUST enable interoperability with non-XMPP messaging systems that support the Common Presence and Instant Messaging (CPIM) specifications published by the Instant Messaging and Presence (IMPP) Working Group. Two corollaries of this requirement are:

2. 定义的方法必须能够与支持即时消息和状态(IMPP)工作组发布的通用状态和即时消息(CPIM)规范的非XMPP消息传递系统实现互操作性。这一要求的两个推论是:

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

* 在签名和/或加密之前,即时消息的格式必须符合[MSGFMT]中定义的CPIM消息格式。

* Prior to signing and/or encrypting, the format of presence information MUST conform to the CPP Presence Information Data Format defined in [PIDF].

* 在签名和/或加密之前,状态信息的格式必须符合[PIDF]中定义的CPP状态信息数据格式。

3. The method MUST follow the required procedures (including the specific algorithms) defined in [CPIM] and [CPP]. In particular, these documents specify:

3. 该方法必须遵循[CPIM]和[CPP]中规定的程序(包括特定算法)。这些文件特别规定:

* Signing MUST use [SMIME] signatures with [CMS] SignedData.

* 签名必须使用带有[CMS]签名数据的[SMIME]签名。

* Encryption MUST use [SMIME] encryption with [CMS] EnvelopeData.

* 加密必须使用[CMS]信封数据的[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].

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]中所述,对广播存在进行签名或加密(此处定义的方法仅适用于定向存在)。

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节要求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. 在<message/>节的<e2e/>子节中包含的XML CDATA节(参见[XML]的第2.7节)中提供生成的签名和/或加密对象,其中<e2e/>元素由下面第9节中更详细地指定的“urn: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?
        
   |   Content-type: Message/CPIM
   |
   |   From: Juliet Capulet <im:juliet@example.com>
   |   To: Romeo Montague <im:romeo@example.net>
   |   DateTime: 2003-12-09T11:45:36.66Z
   |   Subject: Imploring
   |
   |   Content-type: text/plain; charset=utf-8
   |   Content-ID: <1234567890@example.com>
   |
   |   Wherefore art thou, Romeo?
        

Once the sending agent has generated the "Message/CPIM" object, the sending agent may sign it. The result is a multipart [SMIME] object (see [MULTI]) that has a Content-Type of "multipart/signed" and includes two parts: one whose Content-Type is "Message/CPIM" and another whose Content-Type is "application/pkcs7-signature".

一旦发送代理生成了“Message/CPIM”对象,发送代理就可以对其进行签名。结果是一个多部分[SMIME]对象(请参见[MULTI]),其内容类型为“multipart/signed”,包括两部分:一部分内容类型为“Message/CPIM”,另一部分内容类型为“application/pkcs7 signature”。

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

发送代理现在将“multipart/signed”对象包装在XML CDATA节中,该节包含在<e2e/>元素中,该元素作为XMPP消息节的子元素包含,并由“urn:ietf:params:XML:ns:XMPP-e2e”命名空间限定。

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>
        
   |   <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?
        
   |   Content-type: Message/CPIM
   |
   |   From: Juliet Capulet <im:juliet@example.com>
   |   To: Romeo Montague <im:romeo@example.net>
   |   DateTime: 2003-12-09T11:45:36.66Z
   |   Subject: Imploring
   |
   |   Content-type: text/plain; charset=utf-8
   |   Content-ID: <1234567890@example.com>
   |
   |   Wherefore art thou, Romeo?
        

Once the sending agent has generated the "Message/CPIM" object, the sending agent may encrypt it.

一旦发送代理生成了“Message/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节中,该节包含在<e2e/>元素中,该元素作为XMPP消息节的子元素包含,并由“urn:ietf:params:XML:ns:XMPP-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>
        
   |   <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>
        
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节要求3的规定,对“应用程序/pidf+xml”对象进行签名和/或加密。3.在<presence/>节的<e2e/>子节中包含的XML CDATA节(参见[XML]的第2.7节)中提供生成的签名和/或加密对象,其中<e2e/>元素由“urn:ietf:params:XML:ns:xmpp-e2e”命名空间限定。<presence/>节必须包含一个“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]中指定的规则和格式生成“application/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 version="1.0" encoding="UTF-8"?>
   |   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   |             xmlns:im="urn:ietf:params:xml:ns:pidf:im"
   |             entity="pres:juliet@example.com">
   |     <tuple id="hr0zny"
   |       <status>
   |         <basic>open</basic>
   |         <im:im>away</im:im>
   |       </status>
   |       <note xml:lang="en">retired to the chamber</note>
   |       <timestamp>2003-12-09T23:53:11.31</timestamp>
   |     </tuple>
   |   </presence>
        

Once the sending agent has generated the "application/pidf+xml" object, the sending agent may sign it. The result is a multipart [SMIME] object (see [MULTI]) that has a Content-Type of "multipart/signed" and includes two parts: one whose Content-Type is "application/pidf+xml" and another whose Content-Type is "application/pkcs7-signature".

一旦发送代理生成了“application/pidf+xml”对象,发送代理就可以对其进行签名。结果是一个多部分[SMIME]对象(请参见[MULTI]),其内容类型为“multipart/signed”,包括两部分:一部分内容类型为“application/pidf+xml”,另一部分内容类型为“application/pkcs7 signature”。

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

发送代理现在将“multipart/signed”对象包装在XML CDATA节中,该节包含在<e2e/>元素中,该元素作为XMPP消息节的子元素包含,并由“urn:ietf:params:XML:ns:XMPP-e2e”命名空间限定。

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>
        
   |   <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]中指定的规则和格式生成“application/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" encoding="UTF-8"?>
   |   <presence xmlns="urn:ietf:params:xml:ns:pidf"
   |             xmlns:im="urn:ietf:params:xml:ns:pidf:im"
   |             entity="pres:juliet@example.com">
   |     <tuple id="hr0zny"
   |       <status>
   |         <basic>open</basic>
   |         <im:im>away</im:im>
   |       </status>
   |       <note xml:lang="en">retired to the chamber</note>
   |       <timestamp>2003-12-09T23:53:11.31</timestamp>
   |     </tuple>
   |   </presence>
        

Once the sending agent has generated the "application/pidf+xml" object, the sending agent may encrypt it.

一旦发送代理生成了“application/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节中,该节包含在<e2e/>元素中,该元素作为XMPP消息节的子元素包含,并由“urn:ietf:params:XML:ns:XMPP-e2e”命名空间限定。

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>
        
   |   <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>
        
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格式。然而,除了<message/>和<presence/>之外,XMPP还拥有第三个基本节类型(<iq/>),以及在三个核心节类型的任意子元素中包含扩展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类型的能力,因此本备忘录中采用的方法是将任意XMPP数据包含在名为“application/XMPP+XML”的XML媒体类型中,如下文第10节所述。

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

以下示例说明了“application/xmpp+xml”MIME类型的结构。(注:http://jabber.org/protocol/evil'这些示例中使用的名称空间与一个愚人节协议相关联,该协议被编写为RFC3514的即时消息等价物;它仅作为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 version='1.0' encoding='UTF-8'?>
   |   <xmpp xmlns='jabber:client'>
   |     <message
   |         from='iago@example.com/pda'
   |         to='emilia@example.com/cell'>
   |       <body>
   |         I told him what I thought, and told no more
   |         Than what he found himself was apt and true.
   |       </body>
   |       <evil xmlns='http://jabber.org/protocol/evil'/>
   |     </message>
   |   </xmpp>
        

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

示例14:“应用程序/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 version='1.0' encoding='UTF-8'?>
   |   <xmpp xmlns='jabber:client'>
   |     <presence from='iago@example.com/pda'>
   |       <show>dnd</show>
   |       <status>Fomenting dissension</status>
   |       <evil xmlns='http://jabber.org/protocol/evil'/>
   |     </presence>
   |   </xmpp>
        

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

示例15:IQ节,扩展数据包含在“application/xmpp+xml”MIME类型中:

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

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.

与“Message/CPIM”和“application/pidf+xml”对象一样,“application/xmpp+xml”对象将被签名和/或加密,然后封装在<presence/>节的<e2e/>子节中包含的xml CDATA节中(参见[xml]的第2.7节),其中,<e2e/>元素由“urn:ietf:params:xml:ns:xmpp-e2e”命名空间限定。

6. Rules for S/MIME Generation and Handling
6. S/MIME生成和处理规则
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]没有指定如何从证书颁发机构获取证书,而是要求每个发送代理必须已经拥有证书。在撰写本文时,PKIX工作组已经为证书注册制定了两个单独的标准:[CMP]和[CMC]。用于证书注册的方法不在本备忘录的范围内。

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代理如何处理证书,只说明在证书被验证或拒绝后他们会做什么。[CERT]中涵盖了S/MIME认证问题。

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实体在此备忘录上下文中使用的终端实体证书应包含有效的即时消息和状态地址。地址应同时指定为“im:”URI(对于即时消息,如[CPIM]中所定义)和“pres:”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
        
   Each URI MUST be of the form <im:address> or <pres:address>, where
   the "address" portion is an XMPP address (also referred to as a
   Jabber Identifier or JID) as defined in [XMPP-CORE], prepended with
        

the 'im:' or 'pres:' URI scheme. The address SHOULD be of the form <node@domain> (i.e., a "bare JID"), although any valid JID form MAY be used.

“im:”或“pres:”URI方案。地址应为以下格式:<node@domain>(即“裸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“from”属性中包含的JID值必须与签名者证书中提供的JID匹配,但出于匹配目的,应忽略“from”属性中包含的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匹配,但出于匹配目的,应忽略“from”属性中包含的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].

subject alternative name extension在S/MIME中用作传递即时消息和状态地址的首选方式,该地址对应于此证书的实体。证书中存在的任何XMPP地址必须使用[XMPP-CORE]第5.1.1节中指定的ASN.1对象标识符“xmppAddr上的id”进行编码。

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.

如果发送方和接收方在一段时间内参与了一个活动的消息会话,则发送代理应每五分钟包括发送方的证书以及至少一个加密的消息节。在活动消息会话的上下文之外,发送代理应该包括发件人的证书以及每个加密的消息节。发送代理可以包括发送者的证书以及每个加密的存在节。但是,发送代理不应每五分钟包含一次以上的证书。

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:

时间戳包含在“Message/CPIM”和“application/pidf+xml”对象中,有助于防止重播攻击。所有时间戳必须符合[DATETIME],并以UTC表示,无偏移量,包括小数点(视情况而定)。如果没有对发送代理的感知时间或基础时钟时间进行局部调整,发送代理必须确保发送给接收方的时间戳单调增加(如果时钟返回多个请求的相同时间,则必要时增加时间戳中的秒分数)。以下规则适用于接收申请:

o It MUST verify that the timestamp received is within five minutes of the current time.

o 它必须验证收到的时间戳是否在当前时间的五分钟内。

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.

o [CMS-ALG]第2.1节规定的SHA-1消息摘要。

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

o [CMS-ALG]第3.2节规定的RSA(PKCS#1 v1.5)和SHA-1签名算法。

For CMS EnvelopedData:

对于CMS信封数据:

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

o [CMS-ALG]第4.2.1节规定的RSA(PKCS#1 v1.5)密钥传输。

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

o [CMS-AES]中规定的CBC模式下的AES-128加密算法。

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)忽略<e2e/>扩展,(2)忽略整个节,或(3)向发送方返回<service unavailable/>错误,如[XMPP-CORE]中所述。

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

在案例#2中,接收应用程序不得向发送方返回节错误,因为这是成功案例。

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中,接收应用程序可向发送方返回<not acceptable/>错误(如[XMPP-CORE]中所述),可选地由特定于应用程序的错误条件元素<bad timestamp/>补充,如下所示:

Example 16: Recipient returns <not-acceptable/> error:

示例16:收件人返回<not acceptable/>错误:

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

在第4种情况下,接收应用程序应向发送方返回<not acceptable/>错误(如[XMPP-CORE]中所述),可选地由应用程序特定的错误条件元素<unverified signature/>补充,如下所示:

Example 17: Recipient returns <not-acceptable/> error:

示例17:收件人返回<not acceptable/>错误:

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

在情况#5中,接收应用程序应向发送方返回<bad request/>错误(如[XMPP-CORE]中所述),可选地由应用程序特定的错误条件元素<decryption failed/>补充,如下所示:

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

示例18:收件人返回<bad request/>错误:

   <message from='romeo@example.net/orchard' type='chat'>
     <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
     [CDATA section here]
     </e2e>
     <error type='modify'>
       <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <decryption-failed xmlns='urn:ietf:params:xml:xmpp-e2e'/>
     </error>
   </message>
        
   <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. 通过网关的安全通信

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:

实现两个不同服务之间互操作性的常用方法是使用“网关”,该网关解释每个服务的协议并将其转换为另一个服务的协议。CPIM规范(特别是[MSGFMT]和[PIDF]定义了用于符合[IMP-REQS]要求的即时消息和状态服务之间互操作性的通用配置文件。在XMPP服务和非XMPP服务之间通信的情况下,我们可以将此关系可视化如下:

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

本文定义的端到端加密方法能够通过XMPP-CPIM网关交换加密和/或签名即时消息和存在。特别地:

o When a gateway receives a secured XMPP message or presence stanza from the XMPP service that is addressed to a user on the non-XMPP service, it MUST remove the XMPP "wrapper" (everything down to and including the <e2e> and </e2e> tags) in order to reveal the multipart S/MIME object, then route the object to the non-XMPP service (first wrapping it in the protocol used by the non-XMPP service if necessary).

o 当网关从XMPP服务接收到安全的XMPP消息或状态节,该消息或状态节发往非XMPP服务上的用户时,它必须删除XMPP“包装器”(所有内容,包括<e2e>和<e2e>标记),以便显示多部分S/MIME对象,然后将该对象路由到非XMPP服务(如有必要,首先将其包装到非XMPP服务使用的协议中)。

o When a gateway receives a secured non-XMPP instant message or presence document from the non-XMPP service that is addressed to a user on the XMPP service, it MUST remove the non-XMPP "wrapper" (if any) in order to reveal the multipart S/MIME object, wrap the object in an XMPP message or presence "wrapper" (including the <e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP service.

o 当网关从非XMPP服务接收到一个安全的非XMPP即时消息或状态文档,并发送给XMPP服务上的用户时,它必须移除非XMPP“包装器”(如果有),以便显示多部分S/MIME对象,将对象包装在XMPP消息或状态“包装器”(包括<e2e>和<e2e>标记)中,然后将XMPP节路由到XMPP服务。

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

包装的S/MIME对象必须是不可变的,并且不能由XMPP-CPIM网关修改。

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'/>元素是包含“Message/CPIM”、“application/pidf+xml”或“application/xmpp+xml”对象的xml CDATA节(参见[xml]的第2.7节)的包装器。因此,“urn:ietf:params:xml:xmpp-e2e”命名空间没有固有的语义,封装对象的语义由以下规范之一定义:

   o  [MSGFMT] for "Message/CPIM"
   o  [PIDF] for "application/pidf+xml"
   o  [XMPP-CORE] for "application/xmpp+xml"
        
   o  [MSGFMT] for "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].

尽管本文档中指定了“application/xmpp+xml”媒体类型,<xmpp/>元素只是<message/>、<presence/>或<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]).

鉴于“urn:ietf:params:xml:ns:xmpp-e2e”名称空间没有固有的语义,并且只指定了一个使用协议,版本控制是定义封装对象的协议([MSGFMT]、[PIDF]和[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].

“application/xmpp+xml”媒体类型遵循[xml-media]中指定的准则。此MIME类型的根元素是<xmpp/>,如果默认名称空间是[xmpp-CORE]中定义的“jabber:client”或“jabber:server”,则根元素必须包含且仅包含一个子元素,对应于xmpp节类型之一(即消息、状态或iq)。根据[XMPP-CORE]第11.5节,此XML媒体类型的字符编码必须为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.1节至第5.4节)中给出了即时消息和状态协议的详细安全注意事项,特别是[XMPP-CORE](第12.1节至第12.6节)中给出了XMPP的详细安全注意事项。此外,[XML-MEDIA]中指定的所有安全注意事项都适用于“application/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
   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. “应用程序/xmpp+xml”的内容类型注册

To: ietf-types@iana.org

致: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媒体类型名称:应用程序MIME子类型名称:xmpp+xml必需参数:(无)可选参数:(字符集)与RFC 3023中指定的应用程序/xml的字符集参数相同;根据[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的即时消息和状态系统。其他信息:(无)联系人和电子邮件地址,以获取更多信息:IESG<iesg@ietf.org>预期用途:通用作者/变更控制者: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.,Ed.“安全/多用途Internet邮件扩展(S/MIME)版本3.1证书处理”,RFC 38502004年7月。

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.

[CMS]Housley,R.,“加密消息语法(CMS)”,RFC 38522004年7月。

[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.

[CMS-AES]Schaad,J.“在加密消息语法(CMS)中使用高级加密标准(AES)加密算法”,RFC 3565,2003年7月。

[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.

[CMS-ALG]Housley,R.,“加密消息语法(CMS)算法”,RFC3370,2002年8月。

[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.

[CPIM]Peterson,J.,“即时消息的通用配置文件(CPIM)”,RFC3860,2004年8月。

[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.

[CPP]Peterson,J.,“存在的共同特征(CPP)”,RFC 38592004年8月。

[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.

[日期时间]Klyne,G.和C.Newman,“互联网上的日期和时间:时间戳”,RFC 3339,2002年7月。

[DISP] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.

[DISP]Troost,R.,Dorner,S.,和K.Moore,Ed.,“在互联网消息中传达呈现信息:内容处置标题字段”,RFC 2183,1997年8月。

[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[IMP-MODEL]Day,M.,Rosenberg,J.,和H.Sugano,“状态和即时信息模型”,RFC 27782000年2月。

[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.

[IMP-REQS]Day,M.,Aggarwal,S.,Mohr,G.,和J.Vincent,“即时消息/存在协议要求”,RFC 27792000年2月。

[MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.

[MSGFMT]Klyne,G.和D.Atkins,“常见状态和即时消息(CPIM):消息格式”,RFC 3862,2004年8月。

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

[MULTI]Galvin,J.,Murphy,S.,Crocker,S.,和N.Freed,“MIME的安全多部分:多部分/签名和多部分/加密”,RFC 1847,1995年10月。

[PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.

[PIDF]Sugano,H.,Fujimoto,S.,Klyne,G.,Batman,A.,Carr,W.,和J.Peterson,“状态信息数据格式(PIDF)”,RFC 38632004年8月。

[SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[SMIME]Ramsdell,B.,Ed.,“安全/多用途Internet邮件扩展(S/MIME)版本3.1消息规范”,RFC 38512004年7月。

[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[术语]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[XML-MEDIA] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[XML-MEDIA]Murata,M.,St.Laurent,S.和D.Kohn,“XML媒体类型”,RFC 3023,2001年1月。

[XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.

[XMPP-CORE]Saint Andre,P.,Ed.“可扩展消息和状态协议(XMPP):CORE”,RFC 3920,2004年10月。

[XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP) Instant Messaging and Presence", RFC 3921, October 2004.

[XMPP-IM]Saint Andre,P.,Ed.“可扩展消息和状态协议(XMPP)即时消息和状态”,RFC 39212004年10月。

13.2. Informative References
13.2. 资料性引用

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

[CAPS]Hildebrand,J.和P.Saint Andre,“实体能力”,JSF JEP 0115,2004年8月。

[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.

[CMC]Myers,M.,Liu,X.,Schaad,J.和J.Weinstein,“CMS上的证书管理消息”,RFC 2797,2000年4月。

[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.

[CMP]Adams,C.和S.Farrell,“互联网X.509公钥基础设施证书管理协议”,RFC2510,1999年3月。

[DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. Saint-Andre, "Service Discovery", JSF JEP 0030, July 2004.

[DISCO]Hildebrand,J.,Millard,P.,Eatmon,R.和P.Saint Andre,“服务发现”,JSF JEP 0030,2004年7月。

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

[MUC]圣安德烈,P.,“多用户聊天”,JSF JEP 00452004年6月。

[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (3rd ed)", W3C REC-xml, February 2004, <http://www.w3.org/TR/REC-xml>.

[XML]Bray,T.,Paoli,J.,Sperberg McQueen,C.和E.Maler,“可扩展标记语言(XML)1.0(第三版)”,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
        
Appendix A.  Schema for urn:ietf:params:xml:ns:xmpp-e2e
        

The following XML schema is descriptive, not normative.

以下XML模式是描述性的,不是规范性的。

   <?xml version='1.0' encoding='UTF-8'?>
        
   <?xml version='1.0' encoding='UTF-8'?>
        
   <xs:schema
       xmlns:xs='http://www.w3.org/2001/XMLSchema'
       targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
       xmlns='urn:ietf:params:xml:ns:xmpp-e2e'
       elementFormDefault='qualified'>
        
   <xs:schema
       xmlns:xs='http://www.w3.org/2001/XMLSchema'
       targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
       xmlns='urn:ietf:params:xml:ns:xmpp-e2e'
       elementFormDefault='qualified'>
        
     <xs:element name='e2e' type='xs:string'/>
        
     <xs:element name='e2e' type='xs:string'/>
        
     <xs:element name='decryption-failed' type='empty'/>
     <xs:element name='signature-unverified' type='empty'/>
     <xs:element name='bad-timestamp' type='empty'/>
        
     <xs:element name='decryption-failed' type='empty'/>
     <xs:element name='signature-unverified' type='empty'/>
     <xs:element name='bad-timestamp' type='empty'/>
        
     <xs:simpleType name='empty'>
       <xs:restriction base='xs:string'>
         <xs:enumeration value=''/>
       </xs:restriction>
     </xs:simpleType>
        
     <xs:simpleType name='empty'>
       <xs:restriction base='xs:string'>
         <xs:enumeration value=''/>
       </xs:restriction>
     </xs:simpleType>
        
   </xs:schema>
        
   </xs:schema>
        

Author's Address

作者地址

Peter Saint-Andre Jabber Software Foundation

Peter Saint Andre Jabbe软件基金会

   EMail: stpeter@jabber.org
        
   EMail: 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.

本文件及其包含的信息是按“原样”提供的,贡献者、其代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/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的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。