GB/T 25061-2020 信息安全技术 XML数字签名语法与处理规范

　　ICS 35 . 040 L 80

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 25061—2020

　　代替 GB/T 25061—2010

　　信息安全技术

　　XML数字签名语法与处理规范

　　Informationsecuritytechnology—

　　XML digitalsignaturesyntaxandprocessingspecification

　　2020-1 1-19 发布 2021-06-01 实施

　　国家市场监督管理总局国家标准化管理委员会

　　发

　　布

　　GB/T 25061—2020

　　GB/T 25061—2020

　　前 言

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

　　本标准代替 GB/T 25061—2010《信息安全技术 公钥基础设施 XML数字签名语法与处理规范》，与 GB/T 25061—2010 相比，主要技术变化如下：

　　— 增加了新的引用文件(见第 2 章);

　　— 在 KeyInfo 中，增 加 了 SM2KeyValue 类 型 定 义，表 示 SM2 椭 圆 曲 线 密 码 算 法 密 钥 值(见 6 . 5 . 3 . 3) ;

　　— 在 KeyInfo 元素中，增加了 DEREncodedKeyValue 和 KeyInfoReference 子元素，并给出模式定义(见 6 . 5 . 6 和 6 . 5 . 7) ;

　　— 增加了 xmldsig11-schema.xsd 和 xmldsig1-schema.xsd 的定义(见附录 C 中 C.2 和 C.3) ;

　　— 增加了密码杂凑算法 SM3,消息鉴别算法 HMAC-SM3,签名算法 SM2-SM3 的定义(见附录 D中 D. 3 . 2、D. 4 . 3 和 D. 5 . 3) ;

　　— 增加了 XML规范化 1 . 1 算法和独占 XML规范化 1 . 0 算法(见附录 D 中 D. 6 . 3 和 D. 6 . 4) 。

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

　　本标准由全国信息安全标准化技术委员会(SAC/TC 260)提出并归口 。

　　本标准起草单位：北京信安世纪科技股份有限公司、格尔软件股份有限公司、数安时代科技股份有限公司、国家密码管理局商用密码检测中心。

　　本标准主要起草人：汪宗斌、刘婷、郑强、张永强、吕春梅、焦靖伟、史晓峰。

　　本标准所代替标准的历次版本发布情况为：

　　—GB/T 25061—2010 。

　　GB/T 25061—2020

　　信息安全技术

　　XML数字签名语法与处理规范

　　1 范围

　　本标准规定了创建和表示 XML数字签名的处理规则、签名语法、附加的签名语法和证实方法。

　　本标准适用于制作和处理 XML数字签名的应用程序、系统或服务。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。 凡是注 日期的引用文件，仅注 日期的版本适用于本文件 。凡是不注 日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 1988 信息技术 信息交换用七位编码字符集

　　GB/T 13000 信息技术 通用多八位编码字符集(UCS)

　　GB/T 16264 . 8—2005 信息技术 开放系统互连 目录 第 8 部分：公钥和属性证书框架

　　RFC 2045 基于多用途互联网邮件扩展 第 1 部分：互联网消息体格式(Multipurpose Internet Mail Extensions(MIME) Part One : Format of Internet Message Bodies)

　　RFC 3279 互联网 X.509 公钥基础设施的算法和标识符 证书和证书撤销列表轮廓[Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation

　　List (CRL) Profile]

　　RFC 3986 统一资源标识符(URI)：通用语法[Uniform Resource Identifier (URI) : Generic Syn-

　　tax]

　　RFC 4514 轻型目录访问协议(LDAP)：甄别名的字符串表示[Lightweight Directory Access Pro- tocol (LDAP) : String Representation of Distinguished Names]

　　RFC 5480 椭圆曲线密码主体公钥信息(Elliptic Curve Cryptography Subject Public Key Infor-

　　mation)

　　3 术语、定义和缩略语

　　3 . 1 术语和定义

　　GB/T 18793—2002 界定的以及下列术语和定义适用于本文件。

　　3 . 1 . 1

　　分离签名 detachedsignature

　　签名于 Signature元素以外的内容上，签名和数据对象位于不同 XML 文档中的 XML 签名文档的

　　组织形式。

　　GB/T 25061—2020

　　3.1.2

　　封内签名 envelopingsignature

　　签名于 Signature元素中的 Object元素之上，以 Signature 为父元素，将原始文档包含在 Signature

　　中的 XML签名文档的组织形式。

　　3.1.3

　　封皮签名 envelopedsignature

　　签名于整个 XML 内容之上，然后将 Signature作为子元素插入到原始文档中的 XML 签名文档组

　　织形式。

　　3.1.4

　　签名 signature

　　签名者使用私钥对待签名数据的杂凑值做密码运算得到的结果。

　　注：XML签名有三种描述方式：分离签名、封内签名和封皮签名。

　　3.1.5

　　签名应用程序 signatureapplication

　　实现了 Signature元素类型的结构及其子结构的应用程序。

　　3.1.6

　　变换 transform

　　把一个数据从原始状态转化成导出状态的处理。

　　示例：XML规范化，XPath 和 XSLT变换等。

　　3 . 2 符号和缩略语

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

　　?：前一符号出现 0 次或 1 次

　　+：前一符号出现 1 次或多次

　　*：前一符号出现 0 次、1 次或多次

　　CA：证书认证机构(Certificate Authority)

　　CRL：证书撤销列表(Certificate Revocation List)

　　HTTP：超文本传输协议(Hypertext Transfer Protocol)

　　MIME：基于多用途互联网邮件扩展(Multipurpose Internet Mail Extensions)

　　OID：对象标识符(Object Identifier)

　　PKI：公钥基础设施(Public Key Infrastructure)

　　URI：统一资源标识符(Universal Resource Identifier)

　　XML：可扩展置标语言(Extensible Markup Language)

　　XPath: XML路径(XML Path)

　　XSL：可扩展样式表语言(Extensible Stylesheet Language)

　　XSLT : XSL 变换(Extensible Stylesheet Language Transformations)

　　4 XML签名概述

　　4 . 1 概述

　　本章描述了 XML数字签名的结构，第 5 章给出了处理规则、第 6 章签名语法和第 7 章附加的签名

　　GB/T 25061—2020

　　语法，XML格式要求见 GB/T 18793—2002 。

　　XML签名可通过间接方式作用于任意数据对象，处理的步骤是先对数据对象进行杂凑处理，处理后的结果放置在一个元素中，再对得到的元素进行杂凑处理并且通过密码学方法进行签名。 XML 数

　　字签名使用 Signature元素来表示，其结构如下：

　　< CanonicalizationMethod/>

　　(

　　()?

　　) +

　　()?

　　() *

　　签名是通过 URI关联数据对象的。 在 XML 文档内部，签名通过 XML 片段标识符关联本地的数据对象，本地数据可包含在封内签名中，也可包含在封皮签名中。 分离签名作用于外部网络资源或者作用于以兄弟元素形式出现的同一个 XML 文档的本地数据对象，因此这种签名既不是封内签名也不是封皮签名。 一个 XML文档中签名元素(以及它的 ID 和属性值和名字)可与其他元素同时存在，也可和其他元素结合在一起，命名时应注意避免违反 XML标识的唯一性。

　　本标准凡涉及密码算法相关内容，按照国家有关法规实施。

　　签名实例参见附录 A。

　　4 . 2 定义文件用法说明

　　本标准附录 B 为数字签名文档类型定义，附录 C 为 XML数字签名模式定义。

　　在应用本标准时，应将附录 B 和附录 C 的文件存放到应用可访问的位置，例如，假定存放在 IP 地

　　址为 127. 0. 0. 1 的服务器上，各个文件 的路径为：http://127. 0. 0. 1/2001/XMLSchema.dtd、http://

　　127.0.0.1/2000/09/xmldsig-core-schema.xsd、http://127. 0. 0. 1/2009/xmldsig11-schema.xsd、http://

　　127.0.0.1/TR/xmldsig-core1/xmldsig1-schema.xsd,应用可根据实际情况调整存放位置，可使用附录C 中 C. 3 定义的方法来集合这些定义。

　　本标准提及的上述地址(“127 . 0 . 0 . 1”)仅是为了明确一个特定空间，实际应用中可视情况调整。

　　5 处理规则

　　5 . 1 生成

　　5 . 1 . 1 Reference生成

　　对于每个要签名的数据对象，Reference元素生成的步骤如下：

　　a) 根据应用程序的要求，对数据对象进行变换;

　　GB/T 25061—2020

　　b) 计算变换后的数据对象的杂凑值;

　　c) 创建一个 Reference元素，包括一个可选的数据对象的标识，可选的变换元素，密码杂凑算法和杂凑值。

　　5. 1 .2 signature生成

　　Signature元素生成的步骤如下：

　　a) 以 SignatureMethod 指定的签名算法、CanonicalizationMethod 指定的规范化算法和引用生成的 Reference 为内容，创建 SignedInfo 元素。

　　b) 用 SingedInfo 中指定的规范化算法进行处理，并用 SignedInfo 指定的签名算法来计算 Signed- Info 的签名值。

　　c) 构建包括 SignedInfo、Object、KeyInfo 和 SignatureValue 的 Signature 元素。Signature 元素中各个子元素的含义和具体构造方法见第 6 章 。

　　5 . 2 确认

　　5 . 2 . 1 概述

　　确认应包括：

　　a) 引用确认，验证 SignedInfo 中每个 Reference包含的杂凑值;

　　b) 签名确认，使用密码方法对计算 SignedInfo 得到的签名进行签名确认。

　　5 .2 .2 Reference确认

　　引用确认的步骤如下：

　　a) 根据 SignedInfo 中 CanonicalizationMethod 指定的规范化方法来处理 SignedInfo 元素;

　　b) 对于 SignedInfo 中的每个 Reference :

　　1) 获得进行杂凑处理的数据对象;

　　2) 使用 Reference 中指定的密码杂凑算法对结果数据对象计算出杂凑值;

　　3) 将上一步生成的杂凑值和 SignedInfo 中的 DigestValue 元素的值进行比较，如果有不同，那么确认失败。

　　注：SignedInfo 在步骤 a)进行了规范化，应用程序宜确保 CanonicalizationMethod不会产生错误。

　　5.2.3 signature确认

　　Signature 确认应比较以 CanonicalizationMethod 指定的规范化方法和 SignatureMethod 指定的签名方法处理 SignedInfo 的结果是否与 SignatureValue 中的值是否匹配。

　　Signature 确认的步骤如下：

　　a) 从 KeyInfo 或者外部源获得密钥信息;

　　b) 使用 CanonicalizationMethod来获得 SignatureMethod 的规范化形式，然后用得出的结果和上面得到的密钥信息对 SignedInfo 元素进行签名值验证。

　　6 签名语法

　　6 . 1 概述

　　6 . 1 . 1 模式定义

　　签名语法通过 XML模式定义来定义，所有的 XML 模式定义使用下面的 XML 前导说明部分、文

　　GB/T 25061—2020

　　件类型声明和内部实体。

　　模式定义：

　　注：上一行为 XML声明，该行中的

　　示元素的个数，请注意区分。

　　PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://127.0.0.1/2001/XMLSchema.dtd"

　　[

　　xmlns : ds CDATA # FIXED "http://127.0.0.1/2000/09/xmldsig# ">

　　]>

　　xmlns: ds="http://127.0.0.1/2000/09/xmldsig# "

　　targetNamespace="http://127.0.0.1/2000/09/xmldsig# "

　　version = "0 . 1 " elementFormDefault = "qualified">

　　文档类型定义：

　　扩展标记使用 dsig11：名字空间。新的模式定义如下：

　　xmlns: ds="http://127.0.0.1/2000/09/xmldsig# "

　　xmlns: dsig11="http://127.0.0.1/2009/xmldsig11 # "

　　targetNamespace="http://127.0.0.1/2009/xmldsig11 # "

　　version = "0 . 1 " elementFormDefault = "qualified">

　　6. 1 .2 ds：cryptoBinary简单类型

　　定义 ds: CryptoBinary 简单类型，把 XML 中任意长度的整数表示成字节字符串。具体方法是先把

　　整数值转化成高位在前格式的位串，在位串前面补 0 使得位数是 8 的整数倍，去掉开头为零字节(连续8 个 0 的位串)，然后对这个字节串进行 base64 编码，base64 编码遵循 RFC 2045 。

　　注：base64Binary 与 CryptoBinary类型相同，定义一个新的类型主要是兼容不同的使用习惯。

　　模式定义：

　　GB/T 25061—2020

　　6.2 signature元素

　　Signature元素是 XML签名的根元素，Signature元素的组织应遵循下面说明的模式。

　　模式定义：

　　文档类型定义：

　　xmlns CDATA # FIXED ,http://127.0.0.1/2000/09/xmldsig# ,

　　Id ID # IMPLIED >

　　6.3 signaturevalue元素

　　SignatureValue元素包含了数字签名的具体值，通常使用 base64 进行编码。当给出两个 Signa- tureMethod算法时，一个是应实现的，另一个是可选实现的，用户可使用 自己定义的算法。

　　注：封皮签名在计算 SignatureValue 时不包含其自身。

　　模式定义：

　　文档类型定义：

　　Id ID # IMPLIED>

　　GB/T 25061—2020

　　6.4 signedInfo元素

　　6 . 4 . 1 概述

　　SignedInfo 的结构包括规范化算法、签名算法和一个或者多个引用。SignedInfo 元素可包含一个

　　可选的 ID属性，供其他签名或者对象引用。

　　SignedInfo 不包括显式的签名或杂凑属性(例如处理时间、加密设备序列号等)，如果应用程序需要将属性与签名或杂凑相关联，则可在 Object元素内的 SignatureProperties 元素中包含此类信息。

　　模式定义：

　　文档类型定义：

　　SignatureMethod, Reference+) >

　　Id ID # IMPLIED>

　　6 .4 .2 canonicalizationMethod元素

　　CanonicalizationMethod是 SignedInfo 元素中用于指定规范化算法的必要元素，指明签名处理之前进行规范化处理的算法，CanonicalizationMethod元素使用算法标识符和实现需求中给出的算法。应用

　　实现应支持必要的规范化算法。

　　可选用需要的规范化算法，若不明确指定，缺省的规范化算法是 Canonical XML。

　　对 SignedInfo 元素的呈现与规范化算法本身有关。下面的步骤适用于处理 XML节点的算法：

　　基于 XML 的规范化实现，实现带有一个 XPath节点集合，节点集合源于包含 SignedInfo 元素的文档，并指明当前的 SignedInfo,后代、属性、SignedInfo 名字空间节点和它的后代元素。

　　模式定义：

　　文档类型定义：

　　GB/T 25061—2020

　　Algorithm CDATA # REQUIRED>

　　6.4.3 signatureMethod元素

　　SignatureMethod是用来指定进行签名生成和验证算法的必要元素，表明签名操作中用到的密码

　　函数(如密码杂凑算法，公钥算法，MAC,填充方式等)。 这个元素使用算法标识符(算法标识符实例可参考附录 D) 。

　　模式定义：

　　< element name = " HMACOutputLength " type = " ds : HMACOutputLengthType " minOccurs= "0" />

　　文档类型定义：

　　Algorithm CDATA # REQUIRED >

　　6 .4 .4 Reference元素

　　6 . 4 . 4 . 1 概述

　　Reference元素可出现一次或者多次，用来指明密码杂凑算法、杂凑值、签名对象的标识符、签名对

　　象的类型和进行杂凑处理前的一个变换列表。 标识(URI)和变换描述了如何对内容进行杂凑处理。

　　Type属性指明如何处理引用的数据。可选的 ID属性允许 Reference 引用其他的内容。

　　模式定义：

　　GB/T 25061—2020

　　文档类型定义：

　　Id ID # IMPLIED

　　URI CDATA # IMPLIED

　　Type CDATA # IMPLIED>

　　6 . 4 . 4 . 2 URI属性

　　URI 属性使用 URI 引用来标识一个数据对象，URI 和 XML 均使用 GB/T 13000 定义的字符集。

　　但 URI 引用中禁止使用除#，%，[，]外，RFC 3986 中列出的所有非 GB/T 1988 字符和保留字等特定

　　字符。 禁止使用的字符应通过下面的方法进行转义：

　　a) 每个禁止字符按照一个或多个字节转化成 GB/T 13000 编码;

　　b) 任何与一个禁止字符相应的字节序列使用 URI 的转义方法进行转义;

　　c) 用生成的字符序列代替原始的字符。

　　XML签名的应用程序应能解析 URI 语法，并能够依据 HTTP 标准来解析 URI 引用、理解协议的参数和状态信息，处理 HTTP 的状态码。

　　一个资源有多个 URI标识时，应使用最具体的 URI标识。

　　应用程序预先知道对象的标识时，可不提供 URI 属性。

　　URI 的 Type属性包含被签名对象的类型信息，表示成 URI, Type 属性是可选的。

　　例如：

　　Type="http://127.0.0.1/2000/09/xmldsig#Object",或

　　Type="http://127.0.0.1/2000/09/xmldsig# Manifest"

　　Type属性应指向具体的对象，而不是其内容，Type属性是辅助性的，不要求验证 Type 的有效性。

　　6 .4 .4 .3 Reference处理模型

　　签名应用程序不必为了符合本标准而与 XPath规范一致，但对于那些希望充分利用 XML 特性，将XML签名生成作为应用程序的一部分来处理的应用程序则应使用 XPath 数据模型、定义和语法。采用 XPath 的 目的是为那些希望使用这些特征，而又符合 XPath 规范的应用提供一种可选途径。应用可对一个节点集合进行充分的功能替换，并且仅实现本标准需要的那些 Xpath 表达式行为，为了简单起见，本标准通常使用 Xpath术语而不在每个地方都注明。对于“XPath 节点集合”需求可实现一个包含节点集合功能相同的应用程序。应用程序应对 XML 文档采用与 Xpath处理等效的方式处理文档。

　　解析 URI 或者一系列 Transform 的变换结果的数据类型是一个八位位组流或者是一个 Xpath 的

　　节点集合。

　　本标准中所涉及的变换是根据输入定义的。 签名应用程序的正常行为应为：

　　a) 如果数据对象是八位位组流且下一个变换要求一个节点集合，签名应用程序应对字节流进行分析，通过 XML标准处理过程来得出必需的节点集合;

　　b) 如果数据对象是一个节点集合而下一个变换需要八位位组，签名应用程序必须使用规范的XML来把节点集合转化成八位位组流。

　　在需要不同输入的变换中进行变换时，用户可指定替代的变换来覆盖这些缺省的变换，最终的八位

　　位组流包含了受保护的数据，用 DigestMethod指定的密码杂凑算法对这些数据对象进行处理，得出的结果放在 DigestValue 中。

　　GB/T 25061—2020

　　若 URI 引用为非同文档引用，解析 URI 引用的结果应为一个八位位组流。 URI标识的 XML 文档指向同文档引用或应用不要求变换时，签名应用程序不必解析它。

　　若片段出现在一个绝对或者相对 URI 的前面，那么片段的含义由资源的 MIME 类型定义。 对于XML文档，也可通过一个代理来完成签名程序对 URI 的解析(包括对片段的处理)。 如果片段处理不是标准化处理的引用确认可能会失败。 本标准建议 URI 属性不包括片段标识符，而将这种处理过程当

　　作附加的 XPath 变换来进行说明。

　　当片段没有出现在 URI前面时，XML 签名程序应支持空 URI 和无名 Xpointer;若应用程序还要支持任何保存注释的规范化操作，那么建议对同文档的 Xpointer 提供支持。由于应用程序可能无法控制片段的生成，因此所有其他对 Xpointer 的支持都是可选的，所有对无名和外部引用的 Xpointer 的支

　　持也是可选的。

　　6 . 4 . 4 . 4 同文档 URI引用

　　解析同文档引用应产生一个适合规范化 XML 使用的 Xpath 节点集合。特别是，解析一个空 URI应产生一个 Xpath节点集合，该集合包含拥有 URI 属性的 XML文档的每个非注释节点。片段 URI 中#号后面的字符应符合 Xpointer 语法，处理 Xpointer 的时候，应用程序应使用包含 URI 属性的 XML文档的根节点来初始化 Xpointer处理文档。若 Xpointer处理后的结果是一个节点集合时，应用程序应

　　通过下面的方法获得：

　　a) 丢弃点节点;

　　b) 名字空间子资源中包括完整或者部分内容的 XPath节点;

　　c) 用子节点替换根节点(假设它在节点集合里面);

　　d) 把所有元素节点 E替换为 E 和 E 的后代节点(文本、注释、PI 或者元素)以及所有的 E 和它的后代元素的名字空间和属性节点;

　　e) 如果 URI 不是一个完整的 XPointer,那么删除所有的注释节点。

　　解析时应执行步骤 d)的替换。XPointer是使用子树的根节点元素来指明一个 XML文档的语法分

　　析树的子树，而规范化的 XML 把一个节点集合当作节点的集合，在这种情况下，缺少后代节点就会导致在规范形式的内容的不足。

　　步骤 e)用来处理空 URI、裸名指针和子序列 XPointers。当传递一个节点集合时，需要按照有注释和没注释对节点集合进行处理，处理成字节流时会调用 Xpath 表达式(缺省的或者没有注释的)，因此，为了在传递节点集合的时候保留脱模注释的缺省的行为，应去除非完整的 XPointer 的 URI。若要在通过标识符 ID选择元素的时候保留注释，应使用这样的全 XPointer: URI= ,# xpointer(id(,ID,)),;若要在选择整个文档的时候保留注释，应使用这样的全 XPointer: URI= ,# xpointer(/) ,，XPointer 包含了一个含有根节点的简单的 Xpath 表达式，步骤 d)会将该根节点替换为语法分析树的所有节点(所有

　　的后代、所有的属性和所有节点的名字空间)。

　　6 .4 .4 .5 Transforms元素

　　可选的 Transforms 元素包括一个有序的 Transform 元素列表，这些元素描述签名者如何获得将要进行杂凑处理的数据对象，每个 Transform 的输 出都要作为下一个 Transform 的输入，第一个Transform 的输入是解析 Reference元素的 URI 属性所得到的结果，最后一个 Transform 的结果是 Di- gestMethod算法的输入。使用 Transform 后，签名者处理的已经不是原始的文档，而是 Transform 处

　　理后的文档。

　　每个 Transform元素由一个算法属性和与这个算法配套的内容参数构成(如果有参数的话)，算法

　　GB/T 25061—2020

　　属性值指定要进行处理的算法的名字，Transform 内容提供附加的数据来控制算法处理 Transform 输

　　入的过程。

　　在 Reference处理模型中曾经提到，一些 Transform 使用 XPath节点集合为输入，而其他一些需要一个字节流。若实际的输入符号 Transform 的需求，则 Transform 在操作的时候不会更改输入。若Transform 的输入要求和实际输入的格式不同，则实际的输入需要进行一些变换。Transform 可能需要显式的 MIME类型、字符集或者是它们从前面的 Transform 或源数据收到的数据的相关信息，应以Transform 算法参数的形式提供这种数据的特征，通过参数的形式把这些数据特征提供给 Transform

　　算法，且应在算法的规范中描述出来。

　　Transform 例子包括但不仅限于 base64 解码，XML规范化，XPath 过滤和 XSLT。

　　模式定义：

　　文档类型定义：

　　6.4.4.6 DigestMethod元素

　　DigestMethod是指定签名对象的密码杂凑算法的必要元素，使用通用结构来描述算法标识符和实

　　现算法(可参考附录 D) 。

　　如果 URI解析的结果和变换处理的结果是一个 XPath节点集合，则结果应按 Reference 处理模型

　　中规定的方法进行变换;如果 URI解析和变换处理结果是字节流，则不需要进行变换，直接对得出的字节流数据进行密码杂凑算法处理。

　　模式定义：

　　GB/T 25061—2020

　　文档类型定义：

　　Algorithm CDATA # REQUIRED >

　　6.4.4.7 Digestvalue元素

　　DigestValue元素包含了杂凑值编码后的结果，杂凑值应使用 base64 进行编码。

　　模式定义：

　　文档类型定义：

　　6.5 keyInfo元素

　　6 . 5 . 1 概述

　　KeyInfo 是接收者获取确认签名所需密钥材料的可选元素。KeyInfo 可包括的信息有：密钥、名字、

　　证书和其他公开密钥管理信息。 本标准定义了一些简单类型，应用程序可扩展这些类型，也可用 XML名字空间定义自己的密钥标识和交换语义来代替它们。 但密钥信息的可信问题(例如，它的真实性或强度)不在本标准讨论范围之内，而应由应用程序来处理。

　　接收者能从应用程序的上下文中获取验证签名的密钥时可忽略 KeyInfo 元素，KeyInfo 中的多个声明可指向同一个密钥，应用程序应实现 KeyValue,但不一定实现 RetrievalMethod。应用也可通过引

　　入不同名字空间的元素，来定义和使用 自 己选择的任意机制。

　　KeyInfo 的子元素(例如 X509Data)的模式/文档类型定义规范允许其内容被其他命名空间的元素扩展，但仅在忽略扩展元素时仍然安全才有效，否则扩展元素(包括元素的替代结构)应为 KeyInfo 的子

　　元素。

　　下面列出了 disg：名字空间中已分配标识符的 KeyInfo 类型，可在 RetrievalMethod 元素的 Type属性中使用它们来描述一个远程的 KeyInfo 结构。

　　—http://127.0.0.1/2000/09/xmldsig# RSAKeyValue

　　—http://127.0.0.1/2000/09/xmldsig# X509Data

　　下面列出了在 dsig11：名字空间中分配标识符的其他 KeyInfo 类型。

　　http://127.0.0.1/2009/xmldsig11 # SM2KeyValue

　　GB/T 25061—2020

　　http://127.0.0.1/2009/xmldsig11 # DEREncodedKeyValue

　　除了上面用 XML结构定义的这些类型，本标准定义了一个类型来表示二进制的数字证书(又称X509 证书)，具体定义见 GB/T 16264 . 8—2005 的第 7 章 。

　　http://127.0.0.1/2000/09/xmldsig# rawX509Certificate

　　模式定义：

　　文档类型定义：

　　Id ID # IMPLIED >

　　6.5.2 keyName元素

　　KeyName元素应包含一个字符串(其中的空格是不能忽略的)，签名者可用它与接收者传递密钥标识符。KeyName应包含签名的密钥对的相关标识符，也可包括对其他与协议相关的间接标识密钥对的

　　信息。

　　模式定义：

　　文档类型定义：

　　6.5.3 keyvalue元素

　　6 . 5 . 3 . 1 概述

　　KeyValue应包含唯一有效确认签名的公钥。KeyValue 元素可包括在外部定义的公钥值，它们以

　　PCDATA 或外部名字空间的元素类型来表示。 在附录 A 中给出了 SM2 公开密钥的结构化格式的实例。

　　GB/T 25061—2020

　　模式定义：

　　文档类型定义：

　　6.5.3.2 RSAkeyvalue元素

　　标识符：

　　Type="http://127.0.0.1/2000/09/xmldsig# RSAKeyValue"

　　(可用在 RetrievalMethod 或者 Reference元素中用来表示类型)

　　RSA 密钥值有两个域：模和指数

　　实例：

　　xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOoc LZAtNfyxSZDU16ksL6WjubafOqNEpcwR3RdFsT7bCqnXPBe5E

　　Lh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV5foK5hhmbktQhy

　　Ndy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=

　　AQAB

　　任意长度的整数应遵循 XML 中 ds: CryptoBinary类型的定义，用 XML表示为字节串。

　　模式定义：

　　文档类型定义：

　　6.5.3.3 SM2keyvalue元素

　　标识符：

　　GB/T 25061—2020

　　Type="http://127.0.0.1/2009/xmldsig11 # SM2KeyValue"

　　(可用在 RetrievalMethod 或者 Reference元素中用来表示类型)

　　SM2KeyValue元素定义在 http://127.0.0.1/2009/xmldsig11#名字空间中。

　　SM2 公钥由域参数和 PublicKey两部分组成。

　　实例：

　　< SM2KeyValue xmlns="http://127.0.0.1/2009/xmldsig11 # ">

　　BDanuWjsEP0Ki2ursklRv+pBeXNnGFkrS2Veu/FrudFKFTiscMJ1TCa0K23Lk0 +L7HIGz+SWFZZjDAnHPD7n+YQ

　　域参数可通过引用使用 dsig11: NamedCurve元素编码。命名曲线由 URI 属性指定，通过 OID 定义。程序应支持 dsig11: NamedCurve元素和 OID 为 1.2.156.10197.1.301 的 256 位素域椭圆曲线。

　　PublicKey元素包含该点 x 和 y坐标二进制的 Base64 编码。其值计算方法如下：

　　a) 首先将字段元素 x 和 y转换为八位字符串，然后将椭圆曲线点(x，y)转换为八位字节字符串，再将转换结果前面加上 0x04 , OID 为 1.2.156.10197.1.301 时公钥的 x分量和y分量的长度为 256 比特;

　　b ) Base64 对步骤 a)中的转换所产生的八位组串进行编码。

　　模式定义：

　　文档类型定义：

　　GB/T 25061—2020

　　6 .5 .4 RetrievalMethod元素

　　KeyInfo 中的 RetrievalMethod元素用于传递存储在另一个位置的 KeyInfo 信息的引用。例如，一个文档内的几个签名使用一个内部或者外部的 X509 证书链来验证签名，每个签名的 KeyInfo 都可用一个 RetrievalMethod元素来引用证书链，而无须每次都使用 X509Certificate元素的完整证书链。

　　除了没有 DigestMethod 或 DigestValue 子元素，RetrievalMethod使用与 Reference 的 URI 属性和Reference处理模型同样的语法和解析引用的行为，且应包含 URI。

　　Type是表示要检索的数据类型的可选标识符。本标准定义了具有相应 XML 结构的 KeyInfo 类型，解析一个 RetrievalMethod 的 Reference 的结果是一个 XML 元素或者是以此元素为根的文档。 KeyInfo 的 rawX509Certificate类型(不包含 XML结构)返回一个二进制 X509 证书。

　　模式定义：

　　文档类型定义：

　　URI CDATA # REQUIRED

　　Type CDATA # IMPLIED >

　　6 . 5 . 5 X509Data元素

　　标识符：

　　Type="http://127.0.0.1/2000/09/xmldsig# X509Data"

　　(在 RetrievalMethod 或者 Reference元素里用来表示类型)

　　KeyInfo 中的 X509Data元素包括一个或多个密钥标识符，或 X509 证书(证书标识符或废止列表)。 X509Data 的内容有 ：

　　a) 至少应使用一个下列元素类型中的元素，当描述或者关联同一个证书时，可一同使用或多次使用下列元素;

　　b) 具体的内容如下：

　　● X509IssuerSerial元素，应包含一个符合 RFC 4514 的 X509issuer 的甄别名/序列号对，甄别名的生成应当符合甄别名编码规则。

　　● X509SubjectName元素，应包含一个 X509 证书主体名字，应遵循 RFC 4514。

　　● X509SKI元素，应包含 X509 证书主体密钥标识符扩展的 base64 简单编码。

　　● X509Certificate元素，应包含一个 base64 编码的 X509 证书。

　　● X509CRL元素，应包含一个 base64 编码的证书撤销列表(CRL) 。

　　● dsig11 : X509Digest 元 素，应 包 含 一 个 base64 编 码 的 证 书 杂 凑 值。该 元 素 应 包 含

　　GB/T 25061—2020

　　Algorithm 属性标识的密码杂凑算法的 URI,杂凑的输入应为证书的原始八位字节串。

　　● 伴随或补充上述元素的外部名字空间的元素。

　　X509IssuerSerial, X509SKI, X509SubjectName 和 dsig11 : X509Digest 元素应指向证书或者包含确认密钥的证书。所有指向一个特定的证书的元素应放在 X509Data 元素中，而且引用应指向这个

　　X509Data元素 。

　　同一个 密 钥 而 和 不 同 证 书 关 联 的 X509IssuerSerial, X509SKI, X509SubjectName 和 dsig11 : X509Digest元素应分组到一个 KeyInfo 元素中，但是可出现在多个 X509Data元素中。

　　出现在 X509Data 元素中的证书应能关联到确认密钥，可通过包含确认密钥，或作为证书链的一部

　　分包含这个确认密钥，但不要求证书链有序。

　　下面是具体的例子：

　　CN=Zongbin WANG, OU=R&D, O=INFOSEC, L= Haidian District, ST=Beijing, C=CN

　　12345678

　　31d97bd7

　　Subject of Certificate B

　　MIICXTCCA..

　　issuer CN=tootiseCA, OU=R&D, O=INFOSEC, C=CN -->

　　MIICPzCCA...

　　MIICSTCCA...

　　注：对于 PKCS# 7 编码的证书链或者 CRL 没有直接的规定。在一个元素中可出现一组证书和CRL,而且在一个 KeyInfo 元素中可出现多个 X509Data 元素。每当一个元素中出现多个证书

　　时，其中一个证书包含验证签名的公钥。

　　DN 中的字符串(、或)应按照下述方法

　　编码：

　　● 把字符串当作连续的 GB/T 13000 字符串;

　　● 特殊字符应加上“/”来转义，特殊字符包括字符串的最前面“#”或字符中的“，”“+ ”“"”“/” “<”“>”或者“;”;

　　● 转 义 所 有 的 GB/T 1988 控 制 字 符 (GB/T 13000 范 围 内 的 / x00 ~ / x1f) , 即 在 它 们 的GB/T 13000两位 16 进制数之前加上“/”字符;

　　GB/T 25061—2020

　　● 转义所有的后续的空格，用“/20”代替“/”。

　　因 XML文档逻辑上包含字符，而不是字节，故应根据产生该 XML 文档的物理表示所使用的字符编码方法来对结果 GB/T 13000 字符串进行编码。

　　引入 dsig11: X509Digest元素后，可弃用 X509IssuerSerial元素。

　　6.5.6 DEREncodedkeyvalue元素

　　标识符：

　　Type="http://127.0.0.1/2009/xmldsig11 # DEREncodedKeyValue"

　　(可在 RetrievalMethod 或 Reference元素中使用，来识别指示对象的类型)

　　X. 509 证书的主体公钥信息字段中公钥算法和值，编码的要求见 GB/T 20518—2018 中 5 . 2 . 3 . 7,编

　　码后再进行 base64 简单编码。

　　对于本标准中支持的密钥类型，下面的标准文件标识了密钥/算法类型的主体公钥信息格式和相关OID值：

　　—SM2：见 GB/T 35276—2017 中 7 . 1 ;

　　—RSA：见 RFC 3279 ;

　　—EC：见 RFC 5480 。

　　自定义扩展密钥类型可见下面的方式。

　　模式定义：

　　6.5.7 keyInfoReference元素

　　KeyInfo 中的 KeyInfoReference元素用于传递 KeyInfo 元素的位置引用。例如，文档中的多个签名可能使用同一个证书链验证的密钥。每个签名的 KeyInfo 可使用一个 KeyInfoReference元素来引用这个证书链，而不是证书链包含多个 X509Certificate元素的序列。

　　KeyInfoReference 的使用与 Reference 的 URI 属性和 Reference处理模型相同的语法，但没有子元

　　素且要求使用 URI 属性。

　　KeyInfoReference取得的结果应为一个 KeyInfo 元素，或者一个 以 KeyInfo 为根元素 的 XML

　　文档。

　　模式定义：

　　GB/T 25061—2020

　　6.6 object元素

　　标识符：

　　Type=http://127.0.0.1/2000/09/xmldsig# Object(可用在 Reference元素中表示类型。)

　　Object是可包含任何数据的可选元素，可出现一次或多次。Object 元素可包括可选的 MIME 类

　　型、ID 和编码属性。

　　Object 的编码属性可用 URI方式标识 Object所用编码(例如一个二进制文件)。

　　MimeType 可选属性是描述 Object 中数据编码的字符串值，具体的类型定义见 RFC 2045,此属性纯粹是辅助性的，本标准不要求对 MimeType 信息进行验证，应用程序应处理标准类型编码和签名确认编码的变换。例如，如果对象中包括 base64 编码的 PNG,那么 Encoding 可指定为 base64 并且 Mim- eType指定为“image/png”。

　　SignedInfo 或 Manifest 通过 Reference 来引用 Object 的 Id, Object 元素常用于封内签名，被签名的对象将成为签名元素的一部分。对整个 Object元素计算杂凑值，包括开始和结束标签。

　　模式定义：

　　文档类型定义：

　　Id ID # IMPLIED

　　MimeType CDATA # IMPLIED

　　Encoding CDATA # IMPLIED >

　　7 附加的签名语法

　　7 . 1 概述

　　下面描述 Manifest 和 SignatureProperties 元素，并描述如何处理 XML 处理指令和注释。这些元素可出现在上级容模型允许的任何地方;Signature 内容模型应出现在 Object 中。本章为可选内容，应

　　用系统可根据实际情况选用。

　　7 .2 Manifest元素

　　标识符：

　　GB/T 25061—2020

　　Type=http://127.0.0.1/2000/09/xmldsig# Manifest(可用在 Reference元素中表示类型)

　　Manifest元素提供一张 Reference列表，与 SignedInfo 中的列表不同，Manifest列表中的应用程序

　　应规定实际上使用了哪个密码杂凑算法来核对引用的数据对象，还应规定如果对象不可访问或者杂凑

　　值比较失败时，采取什么措施。若从 SignedInfo 中指向 Manifest,应用签名确认行为来验证 Manifest本身的杂凑值。应用程序可自主决定如何验证 Manifest 中的杂凑值。若从一个 Manifest 中引用另一个 Manifest,则导致不能验证这种两层嵌套的杂凑值。

　　模式定义：

　　文档类型定义：

　　Id ID # IMPLIED >

　　7.3 signatureproperties元素

　　标识符：

　　Type=http://127.0.0. 1/2000/09/xmldsig # SignatureProperties(可用在 Reference 元素中来表

　　示类型。)

　　SignatureProperty元素中应存放关于签名生成的任何附加信息(如：时间/日期戳，生成签名时使

　　用的密码硬件的序列号)。

　　模式定义：

　　GB/T 25061—2020

　　文档类型定义：

　　Id ID # IMPLIED >

　　Target CDATA # REQUIRED

　　I ID # IMPLIED >

　　7.4 signature元素中的处理指令

　　本标准的语法与处理没有使用 XML处理指令。

　　注：如果 CanonicalizationMethod没有去掉应用程序放在 SignedInfo 中的处理指令，那么它们也会被进行签名处理。所有 CanonicalizationMethod都包含处理指令。如果一个处理指令是签名处理内容的一部分，那么对处理指令

　　的任何改变都会导致签名失败。

　　7.5 signature元素中的注释

　　本标准的语法与处理没有使用 XML 注释。

　　注：如果 CanonicalizationMethod 不去掉 SignedInfo 中的注释或者其他引用的 XML,那么它们都会被进行签名处

　　理 。 因此，如果保留了它们，任何注释的改变都会导致签名失败;同样，如果不指定忽视注释的规范化/变换方法(如规范化的 XML) ,对于任何 XML数据的 XML签名都会受到注释变化的影响。

　　8 证实方法

　　使用人员在检测签名消息是应验证其是否符合 6 . 1 、6 . 2 、6 . 3 、6 . 4 、6 . 5 及 6 . 6 的要求，若使用了附加的签名消息，还应验证是否符合 7 . 2、7 . 3 的要求，各个元素的具体示例参见附录 A。

　　GB/T 25061—2020

　　附 录 A

　　(资料性附录)

　　XML数字签名实例

　　A.1 简单实例

　　A.1 . 1 概述

　　下面是符合 XML规范的描述 HTML4 内容的分离签名的例子。

　　[s01] < Signature Id = " MyFirstSignature" xmlns = " http://127. 0. 0. 1/2000/09/xmldsig

　　# ">

　　[s02]

　　[s03]

　　[s04a]

　　[s04b] Algorithm="http://127.0.0.1/2001/04/xmldsig-more#sm2-sm3"/>

　　[s05]

　　[s06]

　　[s07]

　　[s08]

　　[s09a]

　　[s09b] Algorithm="http://127.0.0.1/2001/04/xmldsig-more#sm3"/>

　　[s10a] BZT3Gm27GRJs+4fdlf2J+vNWZ5ybI48cg04PtaIJUhE=

　　[s10b]

　　[s11]

　　[s12]

　　[s13a] x114qrUK7I8fU94Xfmh88DUaLeaSAeWpy6c/

　　[s13b] jbzohF6qszDkvmHy0FDufomhi30asLEkP2DCdfeeM5IMfIpn0w = =

　　ureValue>

　　[s14]

　　[s15a]

　　[s15b]

　　[s15c]

　　[s15d] BMKRxUw7j8ThPCi8FG4n4k4xm6XhsgcM0K5LIO86L

　　[s15e] HVqUOl + R3pLeNAVhg00yjXZispILbmKuImCIIrEin8fH68 =

　　PublicKey>

　　[s15f]

　　[s15g]

　　[s16]

　　[s17]

　　其中，[s02-12] SignedInfo 元素是必需的，实际上它就是要进行签名的信息。SingedInfo 的确认包

　　GB/T 25061—2020

　　括两个必备的处理过程：在 SingedInfo 上的 Signature 确认和在 SingedInfo 中的每个引用杂凑的确认。要注意的是，计算 SignatureValue 使用的算法在 SignatureValue 元素处于 SignedInfo 范围外时，也被

　　包括在要签名的信息中。

　　[s03] 把 SignedInfo元素当作签名操作的一部分进行杂凑处理之前，先使用规范化算法对它进行

　　规范化。 要注意，这个例子以及本附录的所有的例子都不是规范化的形式。

　　[s04] 使用 SignatureMethod算法把规范化的 SignedInfo 转换成 SignatureValue,它是一个密码杂

　　凑算法和一个依赖于密钥的算法，还可能和其他算法(如 RSA-SHA1 的填充算法)的结合，将算法名字进行签名，以抵御那种替换成算法复杂度较弱的算法的攻击。 为了提高应用互操作性，尽管是否使用这些算法完全取决于签名的创建者，本附录仍列举了一系列的签名算法，本附录推荐了一些，也允许用户声明 自 己的算法。

　　[s05-11] 每个 Reference元素包括密码杂凑算法和对标识出的数据对象进行处理后的杂凑结果，

　　也可包括产生杂凑处理输入的变换，通过计算数据对象的杂凑值并且对该值进行签名，从而为该数据对象加上签名，随后可通过引用确认和签名确认来检验签名结果。

　　[s14-16] KeyInfo 指示用来确认签名的公钥。标识的可能形式包括证书，密钥名称和密钥交换算法和信息。KeyInfo 是可选的有两个原因，第一：签名者可能不愿意把公钥信息展现给文档处理的各方;第二：公钥信息可能在应用的上下文中就能够得到，不用显式的表示出来。由于 KeyInfo 在 Singed- Info 的外部，如果签名者想把公钥信息也加入签名信息中，使用 Reference 可很容易来标识它并把 Key- Info 加入签名中。

　　A.1 .2 更多 Reference的内容

　　[s05]

　　[s06]

　　[s07]

　　[s08]

　　[s09]

　　[s10] BZT3Gm27GRJs + 4fdlf2J + vNWZ5ybI48cg04PtaIJUhE =

　　gestValue>

　　[s11]

　　其中，[s05] Reference 可选的 URI 属性标识待签名的数据对象。在一个数字签名中，最多只能有一个 Reference忽略该属性。

　　[s05-s08]此标识与变换一起描述了由签名者提供以何种形式进行杂凑处理来获得签名数据信息。

　　只要杂凑核实，验证者可用另外一种方法来获得杂凑值。 特殊情况是，验证者有可能从一个不同的位置来获得内容，比如说从本地存储而不是 URI 指定的地方。

　　[s06-s08] 变换是一个可选的有序的处理步骤列表，在对资源内容进行杂凑处理之前先用这些步骤对它们进行处理。变换可能包括如下的操作：规范化，编码、解码(包括压缩和解压缩)，XSLT, Xpath, XML Schema验证或者 XInclude。Xpath 变换使得签名者获得忽略源文档其中一部分的文档。因此，

　　那些排除在外的文档可进行改变而不会影响签名的有效性。 例如，如果被签名的资源包括签名本身，就得使用这种变换把签名从它自身的计算中排除出去。 如果变换元素不存在，资源的内容将被直接进行杂凑处理。 尽管规范已经推荐了应有的(和可选的)规范化和解码算法，用户指定 自 己 的变换也是允许的。

　　[s09-s10] 对数据进行变换操作后，使用 DigestMethod 算法来产生 DigestValue。对 DigestValue

　　GB/T 25061—2020

　　的签名就是把资源的内容和签署者的密钥绑定到一起。

　　A.2 object和 signatureproperty扩展实例

　　本附录展示了 XML数字签名处理的概念(数据完整性和消息认证)，希望表示其他语义的应用应依赖诸如 XML, RDF 等其他的技术。 签名应用程序应注意它所签名的内容，接收应用程序但不必明

　　白那些语义。任何关于签名生成的内容都可位于 SignatureProperty 元素中。必需的 Target 属性把Signature元素指向属性应用到的 Signature元素上。

　　考虑上面的例子，加入一个附加的指向一个包括 SignatureProperty元素的本地对象的引用。

　　[ ]

　　[p01]

　　[ ] . . .

　　[p02]

　　[ ] . . .

　　[p03]

　　[p04] Type="http://127.0.0.1/2000/09/xmldsig# SignatureProperties">

　　[p05]

　　[p06]

　　[p07]

　　[p08]

　　[p09] < DigestValue > BZT3Gm27GRJs + 4fdlf2J + vNWZ5ybI48cg04PtaIJUhE =

　　gestValue>

　　[p10]

　　[p11]

　　[p12] ...

　　[p13]

　　[p14]

　　[p15]

　　[p16]

　　[p17] 19990914

　　[p18] 14:34:34:34

　　[p19]

　　[p20]

　　[p21]

　　[p22]

　　[p23]

　　其中，[p04] 可选 Reference 中的 Type属性提供了由 URI 标识的资源的相关信息，可指明是 Ob- ject、SignatureProperty还是 Manifest元素，应用程序可根据这一点来对一些 Reference 元素进行特殊的初始化处理。指向一个 Object元素中的一个 XML数据元素的引用应该标明它指向的真正的元素，如果元素内容不是 XML(也许是二进制或者编码后的数据)，引用应标明 Object 和 Reference 类型;如果是，应指明 Object。要注意的是，Type是一个辅助性的属性，签名不需要对它采取任何处理，也不用