ICS33.100.70
中华人民共和国通信行业标准
YD/T2938-2015
扩展消息与表示协议(XMPP)
端到端的签名与对象加密
Extensible messaging and presence protocol (XMPP)-End-to-end signingand object encryption2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
范围·
规范性引用文件
缩略语:
安全消息
安全消息的过程…·
签名消息的示例…·
5.3加密消息的示例.·
6安全表示
安全消息表示的过程
6.2签名表示消息的示例.·
6.3加密表示消息的示例
任意XMPP数据的安全
S/MIME生成和处理的规则·
证书注册:
证书检索·
证书命名·
传输编码…
签名和加密的顺序
证书的列入。
附件和检查签名
共享和核查时间戳:
强制性实现的加密算法·
接收错误处理
通过网关的安全通信
“urn:ietf.params:xml:xmpp-e2e”名字空间“application/xmpp+xml”媒体类型安全性事项·
14IANA事项·
附录A(资料性附录)“urn:ietf:params:xmlns:xmpp-e2e”机制YD/T2938-2015
YD/T2938-2015
本标准是XMPP系列标准之一,本系列标准的名称和结构预计如下:扩展消息与表示协议核心协议:一扩展消息与表示协议即时消息与表示;扩展消息与表示协议地址格式:一扩展消息与表示协议端到端的签名与对象加密。本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位:重庆邮电大学、中国信息通信研究院、国家电网公司信息通信分公司。本标准主要起草人:王平、李瑞雪、王恒、唐晓铭、蔡林沁、魏曼、谢吴飞、兰飞、赵锋、张炎、谢金凤、刘建明、陈星。1范围
扩展消息与表示协议(XMPP)
端到端的签名与对象加密
YD/T2938-2015
本标准定义端到端的扩展消息与表示协议(XMPP)的签名和对象加密方法,主要是允许指定的发件人将签名或加密即时消息发送到一个指定的接受者,指定一个用户可以签名或加密表示消息或任意XMPP节。
本标准适用于即时通讯系统。
规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。IETFRFC2779即时消息/协议需求(InstantMessaging/PresenceProtocolRequirements)IETFRFC2923TCP的路径MTU发现问题(TCPProblemsWithPathMTUDiscovery)IETFRFC3023XML媒体类型(XMLMediaTypes)IETFRFC3688IETFXML注册表(TheIETFXMLRegistry)IETFRFC3852加密消息语法(CryptographicMessageSyntax(CMS))即时消息的通用脚本(CommonProfileforInstantMessaging(CPIM)IETFRFC3923IETFRFC3860
XMPP协议的端到端的签名与对象加密(End-to-End SigningandObjectEncryption fortheExtensibleMessagingandPresenceProtocol (XMPP))[ETFRFC6120o扩展消息与表示协议:核心协议(ExtensibleMessagingandPresenceProtocol(XMPP):Core)
IETFRFC6121扩展消息与表示协议:即时消息与表示(ExtensibleMessagingandPresenceProtocol(XMPP): Instant Messaging and Presence)3缩略语
下列缩略语适用于本文件。
S/MIME
EntityCapabilities
character data
CertificateManagementMessagesoverCMsCertificate Management ProtocolsContent Management System
Service Discovery
Multi-User Chat
SecureMultipurpose InternetMail ExtensionsUniform Resource Location
Extensible Markup Language
实体能力
DTD中的属性类型
CMS的认证管理消息
证书管理协议
内容管理系统
服务搜寻
多用户聊天协议
多用途网际邮件扩充协议
统一资源定位符
可扩展标记语言
YD/T2938-2015
XML-REGTheIETFXMLRegistry
4要求
IETFXML注册表
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和[CPPI中所要求的步骤(包括指定的算法)。准确地说,这些文件规定:
:签名必须使用包含[CMS]签名数据的[SMIME]签名。·加密必须使用包含[CMS]的封装数据的[SMIME]加密。d)为了实现兼容性,发送和接收应用必须在强制实施加密算法下实现指定的算法。本标准还定义了以下内容:
确定实体是否支持此协议。一个实体可以通过尝试发送签名或加密的节或接收一个错误的节(“技术”发现)或者协议不支持而回复的文本消息:或者使用专门的服务发现协议,如[DISCO]或[CAPS]。然而服务发现协议的定义不属于本标准讨论的范围。?在IETFRFC6121中提到的但由于它们在IETFRFC2779中没有被要求,所以这里没有定义的XMPP群聊消息的签名或加密最好在XSFXEP-0045中定义。广播表示的签名或加密在IETFRFC6121中被描述(此处定义的方法只适用于直接存在的)。。通信的签名或加密出现在应用的文本之中,而不是IETFRFC2778和IETFRFC2779中描述的即时消息和表示。
5安全消息
5.1安全消息的过程
为了签名或加密消息,发送代理必须使用下列流程:a)生成如[MSGFMT]定义的“Message/CPIM”目标。b)签名和/或加密Message/CPIM”对象的头部和内容。YD/T2938-2015
c)在包含一个
节的
子元素的XMLCDAT中,提供签名或加密对象的方法。此处的子元素符合‘urm:ietf.params:xml:ns:xmpp-e2e”名字空间。5.2签名消息的示例
下面的例子描述了签名一个消息的步骤。首先,发送代理生成的与[MSGFMT]中指定的规则和格式相一致的“Message/CPIM”对象。示例1:发送者生成“Message/CPIM\对象。Content-type:Message/CPIM
From:JulietCapuletTo:Romeo MontagueDateTime:2003-12-09T11:45:36.66ZI Subject: Imploring
Content-type: text/plain; charset=utf-8/Content-ID:<[email protected]>I Wherefore art thou, Romeo?一旦发送代理生成了“Message/CPIM”对象,发送代理即可签名。其结果是[SMIMEI对象(参看[MULTIJ】。多方[SMIME]对象拥有multipart/signed”的文本类型,也包括下面两部分:一是文本类型为“Message/CPIM”的部分,二是文本类型为“application/pkcs7-signature”的部分。示例2:发送者生成“multipart/signed\对象。IContent-Type: multipart/signed; boundary=next;micalg-shal;
Iprotocol=application/pkcs7-signatureI--next
1Content-type:Message/CPIM
IFrom: Juliet Capulet[To:RomeoMontagueDateTime:2003-12-09T23:45:36.66ZISubject:Imploring
YD/T2938-2015
IContent-type:text/plain; charset-utf-8IContent-ID:<[email protected]>IWherefore art thou,Romeo?
I --next
IContent-Type:application/pkcs7-signatureContent-Disposition:attachment;handling=required;I filename=smime.p7s
I [signed bodypart]
I --next--
发送代理封装XMLCDATA部分中的“multipart/signed”对象,它是被包含在元素中的,此元素又被包括在XMPP消息节的一个子元素中,它是符合“urm:ietf:params:xml:ns:xmpp-e2e”名字空间的。
示例3:发送者生成XMPP消息节。I|<[CDATA[
IContent-Type:multipart/signed;boundary-next:[micalg=shal;
Iprotocol=application/pkcs7-signatureI --next
IContent-type:Message/CPIM
|From:JulietCapuletITo:RomeoMontagueIDateTime: 2003-12-09T23:45:36.66ZSubject:Imploring
I Content-type: text/plain; charset-utf-8[Content-ID:<1234567890@example.com>IWhereforeart thou,Romeo?
I --next
Content-Type:application/pkcs7-signatureIContent-Disposition:attachment;handling-required;[filename=smime.p7s
I [signed body part]
-next-
[
[
5.3加密消息的示例
下面的例子阐明了加密消息的步骤。YD/T2938-2015
首先,发送代理生成与[MSGFMT]中定义的规则和格式相一致的“Message/CPIM”对象示例4:发送者生成“Message/CPIM\对象。IContent-type: Message/CPIMbzxz.net
lFrom:JulietCapuletITo:RomeoMontagueim:romeo@example.net>DateTime:2003-12-09T11:45:36.66ZI Subject: Imploring
I Content-type: text/plain; charset-utf-8[Content-ID:<1234567890@example.com>I Wherefore art thou, Romeo?一旦发送代理生成了“Message/CPIM”的对象,发送代理则可以对它进行加密。示例5:发送者生成加密对象
1U2FsdGVkX19okeKTILxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+veQ1/OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR603Ed2zwcusDImyyz125HFERdDUMBC9JPt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL[Igc1Vzs5/5JecegMieNY24SINyX9HMFRNFpb164vLxYEk55A+3IYbZsluCFT31+a1+GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQri78xNEh+MK8Bx7TBTvi4yHDdzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3[i08IEHzyll6htuEr59ZDAW-
现在发送代理封装XMLCDATA部分中的已加密对象,它是被包含在元素中的,此元素又被包括在XMPP消息节的一个子元素中,它是符合“urn:ietf:params:xml:ns:xmpp-e2e”名字空间的。示例6:发送者生成XMPP消息节。[YD/T2938-2015
/![CDATA[
[U2FsdGVkX19okeKTILxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ[/OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR603Ed2zWcusDImyyz125HFERdDUMBC9IPt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL/Igc1Vzs5/5JecegMieNY24SINyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+aI+GeAvJkvH64LRV4mPbUhENTQ2wbAWnOTvbLlaQEQrii78xNEh+MK8Bx7TBTvi4yH[Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3li08IEHzyll6htuEr59ZDAw
[
[
6安全表示
6.1安全消息表示的过程
为了签名或加密表示消息,发送代理必须使用下列流程:a)生成一个在RFC3863中定义的“application/pidf+xml”对象;b)根据以上的描述,签名或加密“application/pidf+xml”对象:c)在包含一个节的子元素的XMLCDAT中,提供签名或加密对象的方法。此处的子元素符合“urn:ietf:paramsxml:ns:xmpp-e2e名字空间。节必须包括“to”属性,即它必须是一个在RFC6121中定义的直接表示的例子。6.2签名表示消息的示例
下面的例子阐明了签名表示消息的步骤。首先,发送代理生成与RFC3863中指定的规则和格式相一致的“application/pidf+xml”对象。示例l:发送者生成“application/pidf+xml\对象。[|[
[open
[away
[
[retiredtothechamber[2003-12-09T23:53:11.31[
[
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。