YD/T 2938-2015 扩展消息与表示协议 (XMPP) 端到端的签名与对象加密

iCS33.100.70

L79

¥D

中华人民共和国通信行业标准

YD/T2938—2015

扩展消息与表示协议（XMPP)

立而到纟而的金名与对象加密

Extensiblemessagingandpresenceprotocol(XMPP)

—End-to-endsigningandobjectencryption

2015—07-14发布2015-10-01实施

中华人民共和国工业和信息化部发布

YD/T2938-2015

目次

•II

2十弓丨j~|^j/^ijllaessseesscsesaesessee

j^/|^1^=1■•«■»•••••••••«•«»•••••»«•••••

5.1安全消息的过程.......

5.2签名消息的示例......°°3

5.3加密消息的不例"……"…

6安全表不'.................

6„1安全消息表示的过程……

62签名表示消息的示例……

6.3加密表示消息的示例……•

7任意XMPP数据的安全…………■...............10

8S/MIME生成和处理的规则……

8.1证书注册...............……11

82H卜_—j-jj丰丨•令丨*«*丨9*®

8!3~|^|—j--|y

§4舍商令马

8.5签名和加密的顺序.....

86iJT~~~|~!j[JBe®eB®〇*Bee®BBBBB,e®

8.7附件和检查签名*....……

88〇0〇Aac«9«9〇丨e««A»«fi9丨《n«gvoe«

8.9共享和核查时间觀…*………

8.10强制性实现的加密算法…••

9^~p^*卜子

I〇1、丄*|J^|十•»«»**鐧《*««*»«»»«««««攀《«*»*拿鲁*»»«_參■■«««*»■«♦«»•••«

II“um:ietf:params:xml:xmpp-e2e”名字空间.......………•…

12“application/xmpp+xml”媒体类型—...—..........°。

十^=|'j^jji鲁***_*•♦■■**■■••*罾着_*■*♦♦_♦•聲參■»«*_*■•**■**聲峰•《_♦*•■«■■■拿

14丨

附录A(资料性附录）“urn:ietf:params:xml:ns:xmpp-e2e”机制817

YD/T2938-2015

.

刖g

本标准是XMPP系列标准之一，本系列标准的名称和结构预计如下：

一一扩展消息与表示协议核心协议；

一一扩展消息与表示协议即时消息与表示；

一一扩展消息与表示协议地址格式；

一一扩展消息与表示协议端到端的签名与对象加密。

本标准按照GB/T1.1-2009给出的规则起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。

本标准由中国通信标准化协会提出并归口。

本标准起草单位：重庆邮电大学、中国信息通信研宄院、国家电网公司信息通信分公司。

本标准主要起草人：王平、李瑞雪、王恒、唐晓铭、蔡林沁、魏旻、谢昊飞、兰飞、

张炎、谢金凤、刘建明、陈星。

YD/T2938-2015

扩展消息与表示协议（XMPP)

端到端的签名与对象加密

1范围

本标准定义端到端的扩展消息与表示协议（XMPP)的签名和对象加密方法，主要是允许指定的发

件人将签名或加密即时消息发送到一个指定的接受者，指定一个用户可以签名或加密表示消息或任意

XMPP节。

本标准适用于即时通讯系统。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文

件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

IETFRFC2779即时消息/协议需求（InstantMessaging/PresenceProtoco丨Requirements)

IETFRFC2923TCP的路径MTU发现问题（TCPProblemswithPathMTUDiscovery)

IETFRFC3023XML媒体类型（XMLMediaTypes)

IETFRFC3688IETFXML注册表（TheIETFXMLRegistry)

IETFRFC3852加密消息语法（CryptographicMessageSyntax(CMS))

IETFRFC3860即时消息的通用脚本（CommonProfileforInstantMessaging(CPIM))IETFRFC3923

XMPP协议的端到端的签名与对象加密（Erxd-to-EndSigningandObjectEncryptionfortheExtensible

MessagingandPresenceProtocol(XMPP))

IETFRFC6120扩展消息与表示协议：核心协议（ExtensibleMessagingandPresenceProtocol(XMPP):

Core)

IETFRFC6121扩展消息与表不协议：即时消息与表不（ExtensibleMessagingandPresenceProtocol

(XMPP):InstantMessagingandPresence)

3缩略语

下列缩略语适用于本文件。

CAPSEntityCapabilities实体能力

CDATAcharacterdataDTD中的属性类型

CMCCertificateManagementMessagesoverCMSCMS的认证管理消息

CMPCertificateManagementProtocols证书管理协议

CMSContentManagementSystem内容管理系统

DISCOServiceDiscovery服务搜寻

MUCMulti-UserChat多用户聊天协议

S/MIMESecureMultipurposeInternetMailExtensions多用途网际邮件扩充协议

URLUniformResourceLocation统一资源定位符

XMLExtensibleMarkupLanguage可扩展标记语言

YD/T2938-2015

XML-REGTheIETFXMLRegistryffiTFXML注册表

4要求

a)该方法必须定义最小的即时消息和表示的地址签名和加密要求。准确地说该方法必须满足以下要

求。

-该协议必须提供一个方法，以确保一个收到的消息（通知或即时消息）没有被破坏或篡改。

•该协议必须提供一个方法，以确保一个收到的消息（通知或即时消息）没有被其他人记录并返回。

•该协议必须提供一个方法，以确保一个发送的消息（通知或即时消息）只能够被发送者允许的实

体阅读。

*该协议必须允许任何客户端都可以使用一种方法以确保消息保密，没有篡改并成功返回，但协议

不能要求所有的客户端在任何时候都能使用这些方法。

®当A创建订阅给B的表示消息时，该协议必须为A提供一种方法以验证B向A传递的消息是否

准确收到。

•该协议必须为A提供一种方法以核查由B发送的表示消息是否准确。

*该协议必须为A提供一种方法以确保没有第三方C可以看见M的内容。

*该协议必须为A提供一种方法以确保没有第三方C可以篡改M,同时为B提供一种方法以验证

它没有被篡改。

b)该方法必须定义支持由即时消息和表示（IMPP)工作组出版的普通表示和即时消息（CPIM)规

范的非XMPP消息系统的互操作性，有以下要求：

®在此之前签名或加密，即时消息的格式必须符合定义在[MSGFMT]中的CPIM消息格式。

®在此之前签名或加密，表示消息的格式必须符合定义在IETFRFC3863中的CPP表示消息数据

格式。

c)该方法必须遵循定义在IETFRFC3922和[CPP]中所要求的步骤（包括指定的算法）。准确地说，

这些文件规定：

*签名必须使用包含[CMS]签名数据的[SMIME]签名。

®加密必须使用包含[CMS]的封装数据的[SMIME]加密。

d)为了实现兼容性，发送和接收应用必须在强制实施加密算法下实现指定的算法。

本标准还定义了以下内容：

•确定实体是否支持此协议。一个实体可以通过尝试发送签名或加密的节或接收一个错误的节

(“技术”发现)或者协议不支持而回复的文本消息;或者使用专门的服务发现协议，如[DISCO]或[CAPS]。

然而服务发现协议的定义不属于本标准讨论的范围。

®在IETFRFC6121中提到的但由于它们在IETFRFC2779中没有被要求，所以这里没有定义的

XMPP群聊消息的签名或加密最好在XSFXEP-0045中定义。

*广播表示的签名或加密在IETFRFC6121中被描述（此处定义的方法只适用于直接存在的）。

®通信的签名或加密出现在应用的文本之中，而不是IETFRFC2778和IETFRFC2779中描述的即

时消息和表示。

YD/T2938-2015

5安全消息

5.1安全消息的过程

为了签名或加密消息，发送代理必须使用下列流程：

a)生成如[MSGFMT]定义的“Message/CPIM”目标。

b)签名和域加密“Message/CPIM”对象的头部和内容。

c)在包含一个<message/>节的<e2e>f元素的XMLCDAT中，提供签名或加密对象的方法。此处的

<e2e>子元素符合<um:ietf:params:xml:ns:xmpp-e2y名字空间。

5.2签名消息的示例

下面的例子描述了签名一个消息的步骤。

首先，发送代理生成的与[MSGFMT]中指定的规则和格式相一致的“Message/CPIM”对象。

示例1:发送者生成“Message/CPIM”对象。

|Content-type:Message/CPIM

From:JulietCapulet<im:juliet@>

To:RomeoMontague<im:romeo@>

DateTime:2003-12-09T11:45:36.66Z

Subject:Imploring

Content-type:text/plain;charset=utf-8

Content-ID:<1234567890@>

|Whereforeartthou,Romeo?

一旦发送代理生成了“Message/CPIM”对象，发送代理即可签名。其结果是[SMIME]对象（参看

[MULTI])。多方[SMIME]对象拥有“multipart/signed”的文本类型，也包括下面两部分：一是文本类型

为“Message/CPIM”的部分，二是文本类型为“application/pkcs7-sigtiature”的部分。

本例2:发送者生成“multipart/signed”对象。

|Content-Type:multipart/signed;boundary^next;

|micalg=shal;

|protocol=application/pkcs7-signature

—next

Content-type:Message/CPIM

From:JulietCapulet<im:juliet@>

To:RomeoMontague<im:romeo@example〇net>

DateTime:2003-12-09T23:45:36„66Z

Subject:Imploring

YD/T2938-2015

Content-type:text/plain;charset^utf-8

Content-ID:<1234567890@>

Whereforeartthou?Romeo?

-next

Content-Type:application/pkcsV-signature

Content-Disposition:attachment;handling^required;\

filename=smime.p7s

|[signedbodypart]

i

|—next—

发送代理封装XMLCDATA部分中的“multipart/signed”对象，它是被包含在<62〇/>元素中的，此

926/>元素又被包括在XMPP消息节的一个子元素中，它是符合‘urndetfparamsixml^xmpp-eSe7名字

空间的。

示例3:发送者生成XMPP消息节。

〈messageto=’romeo@/orchard’type=5chat’>

<e2exmlns=,urn:ietf:params:xml:ns;xmpp-e2e,>

<![CDATA[

Content-Type:multipart/signed;boundary=next;

micalg^shal;

protocol=application/pkcs7-signature

-next

Content-type:Message/CPIM

From:JulietCapulet<im:juliet@>

To:RomeoMontague<im:romeo@>

DateTime:2003-12-09T23:45;36„66Z

Subject:Imploring

C