信息安全技术公钥基础设施电子签名格式规范(GB-T 25064-2010).pdf

《信息安全技术公钥基础设施电子签名格式规范(GB-T 25064-2010).pdf》由会员分享，可在线阅读，更多相关《信息安全技术公钥基础设施电子签名格式规范(GB-T 25064-2010).pdf（41页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、ICS 35.040L80中中华华人人民民共共和和国国国国家家标标准准GB/T 信息安全技术公钥基础设施电子签名格式规范Information security technology-Public key infrastructure-Electronic signature formats specification（报批稿）-发布-实施国国家家质质量量监监督督检检验验检检疫疫总总局局发布发布GB/T I目次前言.II引言.III1 范围.12 规范性引用文件.13 术语和定义.14 缩略语.25 电子签名组成.25.1 电子签名的主要参与方.25.2 电子签名的类型.25.3 电子签名的验

2、证.76 电子签名的数据格式.106.1 基本数据格式.106.2 验证数据格式.156.3 签名策略要求.19附录 A（规范性附录）电子签名格式的抽象语法记法一（ASN.1）表示.26附录 B（规范性附录）签名策略的抽象语法记法一（ASN.1）表示.33GB/T II前言本标准的附录 A 和附录 B 为规范性附录。本标准由全国信息安全标准化技术委员会（TC260）提出并归口。本标准起草单位：中国科学院软件研究所 信息安全国家重点实验室、信息安全共性技术国家工程研究中心。本标准主要起草人：张凡、冯登国、庄涌、张立武、路晓明、杨婧。GB/T III引言电子商务作为跨越本地、广域、全球网络的新型商

3、务模式，可信对于其成功和连续进行至关重要。以电子方式进行商务活动的公司必须有适合的安全控制机制来保护他们的交易并确保交易方的安全，而电子签名对于保护信息和提供电子商务中的信任是一项重要的安全措施。本标准主要参考了 ETSI TS 101 733 V1.2.2(2000-12)，并以我国电子签名法为纲，针对各种类型的电子签名，可以应用于各种业务，包括个人与公司、公司与公司、个人与政府。本标准独立于应用环境，可以应用在智能卡、GSM SIM 卡、电子签名的特殊应用等各种环境中。根据本标准生成的电子签名并满足中华人民共和国电子签名法第十三条规定，即认为是可靠的电子签名。本标准凡涉及密码算法相关内容，

4、按国家密码管理部门相关规定执行。本标准例子中提及的密码算法如 SHA-1 算法均为举例性说明，具体使用时均须采用国家密码管理部门批准的相应算法。GB/T 1信息安全技术公钥基础设施电子签名格式规范1范围本标准针对基于公钥密码学生成的数字签名类型的电子签名，定义了电子签名与验证的主要参与方、电子签名的类型、验证和仲裁要求。本标准还规范了电子签名的数据格式，包括基本数据格式、验证数据格式、签名策略格式等。本标准适用于电子签名产品的设计和实现，同时相关产品的测试、评估和采购亦可参照使用。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包

5、括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T 16264.8-2005信息技术 开放系统互连 目录 第8部分：公钥和属性证书框架GB/T 16262.1-2006信息技术 抽象语法记法一（ASN.1）第 1 部分：基本记法规范GB/T 20518-2006信息安全技术公钥基础设施数字证书格式GB/T 20520-2006信息安全技术公钥基础设施时间戳规范RFC2630加密消息语法RFC2634S/MIME 的增强安全服务3术语和定义下列术语和定义适用于本标准。3.1签名者 s

6、igner电子签名人，创建电子签名的实体。3.2验证者 verifier电子签名依赖方，对电子签名进行合法性验证的实体。3.3仲裁者 arbitrator当数字签名的有效性发生争议时，对签名者和验证者之间的争议进行仲裁的实体。3.4可信服务提供者 trusted service provider帮助签名者和验证者建立信任关系的一个或多个实体。3.5时间戳 time stamp使用数字签名技术产生的数据，签名的对象包括了原始文件信息、签名参数、签名时间等信息。时间戳机构对此对象进行数字签名产生时间戳，以证明原始文件在签名时间之前已经存在。3.6签名策略 signature policy项目符号和

7、编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 2创建和验证电子签名的一套规则，可以在签名策略的指导下决定一个电子签名是否合法。4缩略语下列缩略语适用于本标准：CA认证机构(Certification Authority)CRL证书撤销列表（Certificate Revocation List）ES电子签名（Electronic Signature）BES

8、基本电子签名（Basis Electronic Signature）ES-A带归档验证数据的电子签名（ES with Archive Validation Data）ES-C带完全验证数据的电子签名（ES with Complete Validation Data）ES-T带时间戳的电子签名（ES with Timestamp）ES-X带扩展验证数据的电子签名（ES with Extended Validation Data）OCSP在线证书状态协议（Online Certificate Status Protocol）RA注册机构（Registration Authority）TSA时间戳机

9、构（Time Stamp Authority）TSP可信服务提供者（Trusted Service Provider）CMS加密消息语法（Cryptographic Message Syntax）ESS增强安全服务（Enhanced Security Services）5电子签名组成5.1电子签名的主要参与方电子签名在其产生和使用的过程中，要涉及多方面的机构和角色，下面列出了本标准定义的四个电子签名主要参与方：a)签名者。签名者是指创建电子签名的实体，当签名者使用预定义的格式对数据进行数字签名时，就代表了它对被签名数据的一种承诺；b)验证者。验证者是指对电子签名进行合法性验证的实体，它可以是单

10、个实体，也可以是多个实体；c)可信服务提供者（TSP）。可信服务提供者是指帮助签名者和验证者建立信任关系的一个或多个实体。它们为签名者和验证者提供了建立信任关系的可信服务，例如证书、交叉证书、时间戳、证书撤销列表、在线证书查询等等。以下列表列出了一些主要的 TSP：1)认证机构（CA），为用户提供公钥证书；2)注册机构（RA），在 CA 给用户颁发证书前，对用户进行认证和注册；3)时间戳机构（TSA），证明数据在某个确定时间前产生；d)仲裁者。仲裁者是指在签名者和验证者之间发生争论时，进行裁决的实体。5.2电子签名的类型5.2.1基本电子签名（BES）基本电子签名（BES）是指包括了签名的基本

11、数据信息的电子签名，这些基本数据信息主要包括以下 3 项：a)签名策略。签名策略定义了在电子签名产生和验证过程中的技术和程序要求，目的是为了满足特定场合的需要。电子签名的参与者应识别其策略，并满足策略的要求；b)数字签名。数字签名是签名者对以下各项信息的综合数据进行的数字签名，信息主要包括：被签名数据的杂凑值；签名策略标识符；其他签名属性；c)签名者提供的其他签名属性。其他签名属性是签名者为了满足签名策略要求或者标准要求而提供的其他属性信息。项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 3BES 的基本组成结构如图 1 所示：图 1

12、BES 组成结构5.2.2验证数据根据电子签名所使用的不同策略，签名者应收集不同的验证数据添加到电子签名中，验证者同样也需要收集与之相联系的验证信息。这些验证数据类型包括：a)数字证书；b)证书撤销信息，如证书撤销列表或在线查询的证书状态信息等；c)时间戳或其他可以用来证明事件发生时间的数据，但作为最小要求，签名者和验证者获得的时间戳必须能够维持完整性，对其的任何修改都可以被检测出来，使得各个参与方都能获得电子签名的准确产生时间。根据电子签名中添加的验证信息的类型和数量，电子签名的安全强度也可以得到不同程度的加强，根据这些验证数据，电子签名可以分为多种类型。5.2.3带验证数据的电子签名5.2

13、.3.1分类总述电子签名可以有以下 5 种格式类型：a)基本电子签名（BES），这类电子签名主要包含数字签名和其他签名者提供的基本信息；b)带时间戳的电子签名（ES-T），这类电子签名在基本电子签名的基础上添加了时间戳，其目的是保证一定程度的长时间的有效性；c)带完全验证数据的电子签名（ES-C），这类电子签名在 ES-T 的基础上，添加了一套完整的用来验证电子签名的数据，例如证书撤销参考信息等等。但其中可能包括了一些参考信息，如一个网址，需要验证者去该网址获得具体数据；d)带扩展的验证数据的电子签名（ES-X），这类电子签名在 ES-C 的基础上，添加了一些额外数据，以适应一些特殊情况；e)

14、带归档时间戳的电子签名（ES-A），这类电子签名是在上述各种电子签名基础上形成的，主要是为长期归档保存电子签名，所以对整个电子签名添加时间戳，以保证长期安全性。签名者在提交电子签名时，至少应给出 BES 格式的签名，在某些情况下可以决定是否提供 ES-T 格式的电子签名，在某些极端情况下可以提供 ES-C 格式的电子签名。如果签名者没有提供 ES-T，则验证者可在收到电子签名时立即自行创建一个 ES-T，或者保存一个接收签名时间的安全记录。验证者的这二种方法都可以为验证时间提供一个独立的证据，而验证时间实际上应接近电子签名的创建时间，使得其可以有足够证据来防止对签名的否认。如果签名者没有提供

15、ES-C，验证者可在 BES 基础上自行创建一个 ES-C，前提是其可以获得相应的验证数据。除此三种外，ES-X 和 ES-A 均为可选支持格式。5.2.3.2带时间戳的电子签名（ES-T）ES-T 中的时间戳所记录的时间应尽可能的接近 BES 的实际创建时间，以提供最大程度的安全保护。如果签名者没有提供 ES-T，则验证者可在收到电子签名时立即自行创建一个 ES-T。ES-T 的基本组成结构如图 2 所示：项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 4图 2 ES-T 组成结构需要注意，当某些验证数据的安全性受到威胁的时候，数字签

16、名上的时间戳或者一个安全的时间记录都可以帮助保护签名的有效性，只要这些安全性威胁是在签名产生以后发生的。因为时间戳和安全时间记录可以有效证明一份电子签名是在这些安全威胁产生前创建的，所以这份电子签名就仍然可以保持其有效性。5.2.3.3带完全验证数据的电子签名（ES-C）ES-C 格式的电子签名不容易与 BES 同时被创建，因为签名者需要去收集相关的证书信息和证书撤销信息。如果发现一份证书已经被暂停使用，则必须等待到证书暂停期结束。从 BES 被创建到 ES-C 被创建可能需要等待一段足够长的时间，签名者只有满足上述这种情况才能创建一个完整的 ES-C。这样带来的好处是验证者可以获得完整的用来

17、验证 BES 的的数据支持。如果签名者没有提供 ES-C，验证者可在 BES 基础上自行创建一个 ES-C，前提是其可以获得相应的验证数据。ES-C 的基本组成结构如图 3 所示：图 3 ES-C 组成结构这里所提到的证书和证书撤销参考信息，是指验证者可以根据这些参考信息，通过指定的途径获得最终需要的证书和证书撤销信息。如果在实际应用中，不需要对数字签名加盖时间戳，则可以使用下面图 4 的 ES-C1 组成结构。但是，这种情况下应保存验证时间的一个安全记录。图 4 ES-C1 组成结构5.2.3.4带扩展验证数据的电子签名（ES-X）5.2.3.3 所描述的 ES-C 可以扩展成一种新的 ES

18、-X 格式，其目的是为了适应以下需求：项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 5a)如果验证者无法从其他途径获得以下数据，则这些数据可以被添加进电子签名，这种扩展格式称为扩展长验证数据 ES-X0 格式（图 5）：1)签名者的证书；2)构成 CA 证书链所需要的 CA 证书；3)需要的具体证书撤销信息。b)如果 CA 证书链中的任意一个 CA 密钥的安全性可能受到威胁，就有必要添加一个额外的时间戳，统称为扩展时间戳验证数据。这种情况可以使用下面二种格式：1)在 ES-C 的基础上，为整个 ES-C 产生一个时间戳，并添加到电子签名中。这种扩展格式称为 ES-X

19、1 格式（图 6）；2)在 ES-C 的基础上，仅仅对 ES-C 添加的“证书和证书撤销参考信息”产生时间戳，并添加到电子签名中。这种扩展格式称为 ES-X2 格式（图 7）。c)如果以上二种情况同时发生，则需要同时在电子签名中添加二类数据。根据 b)中的不同格式，可以产生 ES-X3 格式（图 8）和 ES-X4 格式（图 9），统称为扩展时间戳长验证数据。本标准定义的各种 ES-X 格式仅为可选格式，是否对其支持也是可选的。ES-X0 的组成结构如图 5 所示：图 5 ES-X0 组成结构ES-X1 的组成结构如图 6 所示：图 6 ES-X1 组成结构ES-X2 的组成结构如图 7 所示

20、：项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 6图 7 ES-X2 组成结构ES-X3 所包含的内容包括完整的证书和证书撤销数据，以及针对所有内容的时间戳，其基本结构如图 8 所示：图 8 ES-X3 组成结构ES-X4 所包含的内容主要有完整的证书和证书撤销数据，以及对“完整的证书和证书撤销数据”上的时间戳，其基本组成结构如图 9 所示：图 9 ES-X4 组成结构5.2.3.5带归档时间戳的电子签名（ES-A）各种算法、密钥、加密数据、加密函数都会随着时间而逐渐降低其安全性，各种证书也会随着时间而纷纷失效，如果要长期保存一个电子签名，就需要在这些成分的安全性降

21、低前对整个电子签名加盖一次时间戳。新加的时间戳尽可能使用比老时间戳更强的算法和密钥。这类额外添加的验证数据称为归档验证数据。考虑到时间戳所使用的证书、算法和密钥也会随着时间而失效或降低安全性，在这种情况发生前，必须加盖新的时间戳。因此，一个 ES-A 可能嵌套了多重时间戳。本标准定义的 ES-A 是可选格式，对其的支持也是可选的。ES-A 的基本组成结构如图 10 所示：项目符号和编号设置格式haha:GB/T 7图 10 ES-A 基本结构5.3电子签名的验证5.3.1验证目标对电子签名的验证必须符合电子签名策略，验证的结果有 3 种情况：a)签名有效。这个结果意味着该电子签名通过了验证，并

22、且符合电子签名策略的所有要求；b)签名无效。签名无效基于以下二种情况：1)电子签名的格式错误；2)数字签名验证失败，例如：数字签名完整性检测失败；验证过程中所使用的数字证书已经无效或者被撤销；c)不完全验证。这个结果意味着电子签名的格式没有错误，数字签名也已经通过验证，但是没有足够的信息判断该电子签名是否符合其签名策略的要求。例如，签名策略需要一些附加信息，这些信息对数字签名的有效性没有任何影响，但是现在因为无法获得，所以无法判断是否符合签名策略。在这种情况下，验证者应根据策略要求用户自行处理“部分正确”的电子签名，也可在信息足够时再度对电子签名进行验证。5.3.2验证过程如 5.2.2 条所

23、述，签名者和验证者都可以收集所有的额外数据来完成一个电子签名的创建和验证，图 11 描述了如何完成一个 ES-C 验证的过程。图 11 ES-C 的验证过程a)在收到签名者的 BES 以后，验证者根据被签名数据和 BES，首先验证数字签名的正确性、完项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 8整性和有效性；b)验证者根据电子签名以及 TSP 提供的数据，检查签名是否符合签名策略的要求；c)如果签名者没有提供时间戳或者没有提供可以信任的时间戳，则验证者此时应自行添加一个时间戳。因此到这一步截止，至少应产生一个 ES-T 电子签名；d

24、)如果签名者没有提供证书和证书撤销参考信息，则验证者需要收集所有必需的证书和证书撤销信息，并在这些数据可以使用后，完成所有的验证过程。然后记录一个完整的证书和证书撤销参考信息，创建 ES-C 电子签名；e)验证者输出验证结果。ES-C 是标准中必须支持的格式，但是验证者可以进一步扩展成需要的 ES-X 或者 ES-A 可选格式。如果签名者没有提供 ES-X，则在验证者完成 ES-C 以后，验证者将可以提供或记录在 ES-C 中使用的完整的证书和证书撤销数据（图 12 中的步骤 f），从而形成 ES-X0 格式，过程如图 12 所示：图 12 验证者创建 ES-X0根据验证者的选择和实际情况，也

25、可以创建一个 ES-X1 电子签名，在整个 ES-C 上加盖时间戳（图13 中步骤 g），过程如图 13 所示：GB/T 9图 13 验证者创建 ES-X1验证者也可以创建一个 ES-X2 电子签名，只在“证书和证书撤销参考信息”上加盖时间戳（图 14中步骤 g），过程如图 14 所示：图 14 验证者创建 ES-X2最后，验证者有必要针对需要长期保存的电子签名创建 ES-A 格式，这种格式不需要马上创建，但应在电子签名中任何一项元素（如算法、密钥、证书等）的安全性受威胁前创建。创建时，验证者需要针对整个电子签名的所有内容加盖时间戳（图 15 中步骤 h），过程如图 15 所示：GB/T 10

26、图 15 验证者创建 ES-A5.3.3仲裁如果签名者和验证者发生争执，则需要提请仲裁者进行仲裁。针对提请仲裁的电子签名类型，有以下这些考虑：ES-C 签名可以作为仲裁使用的签名类型，但必须符合下面 3 个条件：a)仲裁者知道如何获得签名者的证书、所有的交叉认证证书、需要的 CRL 以及 ES-C 可能提到的 OCSP 查询；b)签名所使用的整个证书链都是安全的，链上每个证书密钥的安全性都还未受到威胁；c)在 ES-C 创建时所使用的各种密码学技术，在仲裁时仍然是安全的。如果条件 a）不满足，则原告方需要提供 ES-X0 电子签名。如果条件 b）不满足，则原告方需要提供 ES-X1 或者 ES

27、-X2 电子签名。如果条件 c）不满足，则原告方需要提供 ES-A 电子签名。6电子签名的数据格式6.1基本数据格式本标准中数据格式、语法结构等均采用 GB/T16262.1-2006 规定的 ASN.1 表示描述。本条中的数据格式定义以 RFC2630 中定义的加密消息语法（CMS）和 RFC2634 中定义的增强安全服务（ESS）为基础。对于 RFC2630 和 RFC2634 中已定义的语法结构，本标准直接引用不再给出具体定义。6.1.1总体语法结构电子签名的总体语法结构见 RFC2630 中的定义。6.1.2数据内容类型电子签名中的数据内容类型的语法结构和要求见 RFC2630。6.1

28、.3签名数据内容类型电子签名中的签名数据内容类型的语法结构和要求见 RFC2630。为了确保签名验证方能够正确地使用签名者公钥进行验证，本标准中规定，签名证书属性（SignedAttribute）应包含签名者的签名认证证书的杂凑值，签名证书属性的定义见 RFC2634。6.1.4签名数据类型电子签名中的签名数据类型的语法结构和要求除了符合 RFC2630 的规定外，还应满足以下 3 点：项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 11a)

29、版本号须设置为 3；b)用于签名的签名者证书的标识须经过签名；c)签名数据中必须至少有一个签名者信息。6.1.5封装数据内容信息类型电子签名中的封装数据内容信息类型的语法结构和要求见 RFC2630。其中各字段的含义和要求与RFC2630 中一致，另外还要求字段中必须至少有一个签名者信息。6.1.6签名者信息类型电子签名中的签名者信息类型的语法结构和要求见 RFC2630。每个签名者的信息都用一个签名者信息类型的数据结构表示，对有多个独立签名者的情况，每个签名者都使用一个签名者信息类型的数据结构表示。签名者信息类型中各字段的含义和要求与 RFC2630 中相同，但被签名属性中须包含以下属性：a

30、)内容类型；b)消息摘要；c)签名时间；d)签名证书；e)签名策略标识。其消息摘要的计算流程、消息签名的生成流程见 RFC2630 中的相关规定。消息签名的验证流程除了 RFC2630 中规定的内容外，还应满足以下要求：用于验证签名的签名者的公钥的真实性须使用 ESS 规定的或其他的签名证书属性来验证。6.1.7RFC2630 中引入的强制属性在本标准所规定的电子签名中，下列几种 RFC2630 中定义的属性必须与签名数据一同出现：a)内容类型属性（content-type attribute）。其语法结构定义见 RFC2630；b)消息摘要属性（message-digest attribut

31、e）。其语法结构定义见 RFC2630；c)签名时间属性（signing-time attribute）。其语法结构定义见 RFC2630。该属性中的时间值应是签名者声称已经完成签名过程的时间，本标准中建议时间格式采用 Generalized Time 类型。6.1.8可替代的签名证书属性6.1.8.1符合本标准的电子签名应在签名数据中包含下面两个可选签名证书属性中的一个，而且仅包含一个。选择的依据是：当使用的杂凑函数为 SHA-1 时使用 ESS 签名证书属性，当使用其他杂凑函数时，使用其他签名证书属性。6.1.8.2ESS 签名证书属性ESS 签名证书属性的语法结构定义和要求见 RFC26

32、34。各字段的含义和用法除了 RFC2634 中规定的以外还须满足以下几点：a)ESS 签名证书属性必须是被签名属性，而且不能为空。用于验证签名的证书的标识必须包含在该属性中；b)用于验证签名的证书所对应的 ESS 签名证书属性中 ESSCertID 字段的编码应包含 issureSerial字段，而且 issureSerial 字段内容应该与 SignerInfo 中的 issuerAndSerialNumber 字段内容相符。在签名验证过程中，应检查所使用的验证证书的杂凑值与上述字段中的相应内容是否一致，如不一致，应认定该签名无效。6.1.8.3其他签名证书属性该属性的结构与 ESS 签名

33、证书属性相同，但该属性可以在杂凑函数非 SHA-1 的情况下使用。对ESS 签名证书属性的使用要求同样适用于该属性。该属性的对象标识符（OID，Object Identifier）如下：id-aa-ets-otherSigCert OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs9(9)smime(16)id-aa(2)19 项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 12该属

34、性（OtherSigningCertificate）的语法结构 ASN.1 描述如下：OtherSigningCertificate:=SEQUENCE certs SEQUENCE OF OtherCertID,OtherCertID:=SEQUENCE otherCertHash OtherHash,issuerSerial IssuerSerial OPTIONAL OtherHash:=CHOICE sha1Hash OtherHashValue,-该字段包含一个 SHA-1 的杂凑值otherHash OtherHashAlgAndValueOtherHashValue:=OCTET

35、 STRINGOtherHashAlgAndValue:=SEQUENCE hashAlgorithmAlgorithmIdentifier,hashValue OtherHashValue 6.1.9其他强制属性6.1.9.1签名策略标识本标准要求在签名数据（SignedData）中必须包含一个对签名策略的引用。这个引用可以被显式地标识出来，也可以是通过签名内容或其他外部数据隐式的给出。签名策略定义了产生并验证一个签名的规则，应在每个签名的被签名属性中都包含。签名策略标识属性应为被签名属性。签名策略标识的对象标识符为：id-aa-ets-sigPolicyId OBJECT IDENTIFI

36、ER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs9(9)smime(16)id-aa(2)15 其语法结构的 ASN.1 描述为：Signature-policy-identifier attribute values have ASN.1 type SignaturePolicyIdentifier.SignaturePolicyIdentifier:=CHOICESignaturePolicyId SignaturePolicyId,SignaturePolicyImplied SignaturePolicyImpliedSi

37、gnaturePolicyId:=SEQUENCE sigPolicyId SigPolicyId,sigPolicyHash SigPolicyHash,sigPolicyQualifiers SEQUENCE SIZE(1.MAX)OF SigPolicyQualifierInfoOPTIONALSignaturePolicyImplied:=NULLSignaturePolicyImplied 为 NULL 类型表明了，签名策略是在签名内容或其他外部数据中隐式的给出的。SigPolicyId 字段包含了一个能够唯一标识某个签名策略的对象标识符，其语法结构为：SigPolicyId:=OB

38、JECT IDENTIFIERSigPolicyHash 字段包含了杂凑算法的标识符和对签名策略的杂凑运算结果。如果签名策略是用 ASN.1 定义的，则其杂凑值是对其编码中除去外部类型和长度的部分做杂凑运算的结果，而且杂凑函数算法应在 SignPolicyHshAlg 字段中给出。如果签名策略是用其他语法结构定义的，则其语法结构的类型以及使用的杂凑函数应作为签名策略的一部分给出，或使用签名策略限定符（signature policy qualifier）标明。SigPolicyHash:=OtherHashAlgAndValue签名策略标识符应通过签名策略限定符的其他相关信息限定。签名策略限定

39、符的语义及语法结构是项目符号和编号设置格式haha:GB/T 13与 SigPolicyQualifierId 字段中的对象标识符相关联的，其语法定义如下：SigPolicyQualifierInfo:=SEQUENCE sigPolicyQualifierId SigPolicyQualifierId,sigQualifierANY DEFINED BY sigPolicyQualifierId 本标准给出两种限定符：a)spuri：包含了指向签名策略的 URI 或 URL；b)spUserNotice:包含一个用户通知，当验证签名时该通知应被显示给验证者。SigPolicyQualifie

40、rId:=OBJECT IDENTIFIERid-spq-ets-uri OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs9(9)smime(16)id-spq(5)1 SPuri:=IA5Stringid-spq-ets-unotice OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs9(9)smime(16)id-spq(5)2 SPUserNotice:=SEQUENCE noticeRef Notic

41、eReference OPTIONAL,explicitText DisplayText OPTIONALNoticeReference:=SEQUENCE organization DisplayText,noticeNumbers SEQUENCE OF INTEGER DisplayText:=CHOICE visibleString VisibleString(SIZE(1.200),bmpString BMPString(SIZE(1.200),utf8String UTF8String(SIZE(1.200)6.1.10RFC2630 中引入的可选属性联署签名属性（counters

42、ignature attribute）。其语法结构定义见 RFC2630。联署签名属性在使用时应为未签名属性（UnsignedAttribute）。6.1.11RFC2634 中引入的可选属性RFC2634 中引入的可选属性包含以下属性：a)签名内容引用属性（Signed Content Reference Attribute）。该属性把一个签名数据链接到另一个。可以用于把对消息的回复同原消息联系起来，或者把一个签名数据并入其他签名数据中。该属性应为被签名属性。其语法结构定义见 RFC2634。b)内容标识属性（Content Identifier Attribute）。内容标识属性提供一个被

43、签名内容的标识，该标识可在以后需要对该内容进行引用时使用。该属性的语法结构定义见 RFC2634，在使用时，该属性应为被签名属性。c)内容提示属性（Content Hint Attribute）。内容提示属性用于提供被签名内容的格式信息。可以用于签名者向验证者指明被签名内容的格式。当被签名内容必须显示给验证方看时，该属性必须包含在签名数据中。其语法结构定义见 RFC2634。6.1.12其他可选属性其他可选属性包括以下属性：6.1.12.1承诺类型标识属性在某些情况下，签名者希望通过显式的向验证者表明，签名数据代表了签名者某种承诺。承诺类型标识属性（Commitment Type Indica

44、tionAttribute）用于传达这种信息。该属性应为被签名属性。承诺类型应是签名策略的一部分，或者是一个已经注册的类型。签名策略规定了一个其承认的属性集合。这个承认的属性集合中包含了所有该策略承认的承诺类项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:项目符号和编号设置格式haha:GB/T 14型。只有承认的承诺类型才允许出现在该属性字段中。该属性的对象标识符定义为：id-aa-ets-commitmentType OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkc

45、s(1)pkcs-9(9)smime(16)id-aa(2)16该属性的语法结构 ASN.1 定义为：CommitmentTypeIndication:=SEQUENCE commitmentTypeId CommitmentTypeIdentifier,commitmentTypeQualifier SEQUENCE SIZE(1.MAX)OF CommitmentTypeQualifierOPTIONALCommitmentTypeIdentifier:=OBJECT IDENTIFIERCommitmentTypeQualifier:=SEQUENCE commitmentTypeIde

46、ntifier CommitmentTypeIdentifier,qualifierANY DEFINED BY commitmentTypeIdentifier 本标准给出几种承诺类型：id-cti-ets-proofOfOrigin OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)cti(6)1id-cti-ets-proofOfReceipt OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkc

47、s(1)pkcs-9(9)smime(16)cti(6)2id-cti-ets-proofOfDelivery OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)cti(6)3id-cti-ets-proofOfSender OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)cti(6)4id-cti-ets-proofOfApproval OBJECT I

48、DENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)cti(6)5id-cti-ets-proofOfCreation OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)cti(6)6这些承诺类型含义如下：1)Proof of origin：表明签名者承认其曾生成、认同并发送了该消息；2)Proof of receipt:表明签名者承认其曾接受到该内容的消息；3)Proof

49、of delivery：表明提供该承诺的可信服务提供者已经把某消息传送给了接受者可访问的本地存储中；4)Proof of sender:表明提供该承诺的实体发送过这个消息（但不一定创建了该消息）；5)Proof of approval:表明签名者认同该消息的内容；6)Proof of creation:表明签名者创建了该消息（但并不一定认同或发送过该消息）。6.1.12.2签名者位置属性签名者位置属性（Signer Location）用于指定一个表明签名者所处地理位置的助记符。这个助记符应在签名者所在的国家注册，并在公共电报服务（Public Telegram Service）中使用。该属性应

50、为被签名属性。该属性的对象标识符为：id-aa-ets-signerLocation OBJECT IDENTIFIER:=iso(1)member-body(2)us(840)rsadsi(113549)pkcs(1)pkcs-9(9)smime(16)id-aa(2)17该属性的语法结构 ASN.1 定义为：SignerLocation:=SEQUENCE -下列的内容应至少有一项出现countryName 0 DirectoryString OPTIONAL,项目符号和编号设置格式haha:GB/T 15localityName 1 DirectoryString OPTIONAL,po