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

ICS35.040

L80

中华人民共和国国彖标准

GB/T25064—2010

信息安全技术公钥基础设施

电子签名格式规范

Informationsecuritytechnology—Publickeyinfrastructure—

Electronicsignatureformatsspecification

2010-09-02发布2011-02-01实施

GB/T25064—2010

目次

,、/d•、-T

刖有I

引言n

1范围1

2规范性引用文件1

3术语和定义1

4缩略语2

5电子签名组成2

5.1电子签名的主要参与方2

5.2电子签名的类型2

5.3电子签名的验证7

6电子签名的数据格式10

6.1基本数据格式10

6.2验证数据格式15

6.3签名策略要求19

附录A(规范性附录)电子签名格式的抽象语法记法一(ASN.1)表示27

附录B(规范性附录)签名策略的抽象语法记法一(ASN.1)表示34

参考文献39

GB/T25064—2010

■ir■■i

刖吕

本标准的附录A和附录B为规范性附录。

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

本标准起草单位：中国科学院软件研究所信息安全国家重点实验室、信息安全共性技术国家工程研

究中心。

本标准主要起草人：张凡、冯登国、庄涌、张立武、路晓明、杨嬪。

T

GB/T25064—2010

引言

电子商务作为跨越本地、广域、全球网络的新型商务模式，可信对于其成功和连续进行至关重要。

以电子方式进行商务活动的公司必须有适合的安全控制机制来保护他们的交易并碓保交易方的安全,

而电子签名对于保护信息和提供电子商务中的信任是一项重要的安全措施。

本标准主要参考了ETSITS101733VI.2.2(2000-12),并以我国电子签名法为纲，针对各种类型

的电子签名，可以应用于各种业务，包括个人与公司、公司与公司、个人与政府。本标准独立于应用环

境，可以应用在智能卡、GSMSIM卡、电子签名的特殊应用等各种环境中。根据本标准生成的电子签

名并满足《中华人民共和国电子签名法》第十三条规定，即认为是可靠的申.子签名.

本标准凡涉及密码算法相关内容，按国家密码管理部门相关规定执行。

本标准例子中提及的密码算法如SHA-1算法均为举例性说明，具体使用时均须采用国家密码管理

部门批准的相应算法。

n

GB/T25064—2010

信息安全技术公钥基础设施

电子签名格式规范

1范围

本标准针对基于公钥密码学生成的数字签名类型的电子签名，定义了电子签名与验证的主要参与

方、电子签名的类型、验证和仲裁要求。本标准还规范了电子签名的数据格式，包括基本数据格式、验证

数据格式、签名策略格式等。

本标准适用于电子签名产品的设计和实现，同时相关产品的测试、评估和采购亦可参照使用。

2规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有

的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究

是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。

GB/T16264.8-2005信息技术开放系统互连目录第8部分:公钥和属性证书框架(ISO/

IEC9594-8:2001,IDT)

GB/T16262.1—2006信息技术抽象语法记法一(ASN.1)第1部分：基本记法规范(ISO/

IEC8824-1：2002,IDT)

GB/T19713—2005信息技术安全技术公钥基础设施在线证书状态协议

GB/T20518—2006信息安全技术公钥基础设施数字证书格式

GB/T20520—2006信息安全技术公钥基础设施时间戳规范

RFC2630加密消息语法

RFC2634S/MIME的增强安全服务

3术语和定义

下列术语和定义适用于本标准。

3.1

签名者signer

电子签名人，创建电子签名的实体。

3.2

验证者verifier

电子签名依赖方，对电子签名进行合法性验证的实体。

3.3

仲裁者arbitrator

当数字签名的有效性发生争议时,对签名者和验证者之间的争议进行仲裁的实体。

3.4

可信服务提供者trustedserviceprovider

帮助签名者和验证者建立信任关系的一个或多个实体。

3.5

时间戳timestamp

使用数字签名技术产生的数据，签名的对象包括了原始文件信息、签名参数、签名时间等信息。时

1

GB/T25064—2010

间戳机构对此对象进行数字签名产生时间戳，以证明原始文件在签名时间之前已经存在。

3.6

签名策略signaturepolicy

创建和验证电子签名的一套规则，可以在签名策略的指导下决定一个电子签名是否合法。

4缩略语

下列缩略语适用于本标准：

CA认证机构(CertificationAuthority)

CRL证书撤销列表(CertificateRevocationList)

ES电子签名(ElectronicSignature)

BES基本电子签名(BasisElectronicSignature)

ES-A带归档验证数据的电子签名(ESwithArchiveValidationData)

ES-C带完全验证数据的电子签名(ESwithCompleteValidationData)

ES-T带时间戳的电子签名(ESwithTimestamp)

ES-X带扩展验证数据的电子签名(ESwithExtendedValidationData)

OCSP在线证书状态协议(OnlineCertificateStatusProtocol)

RA注册机构(RegistrationAuthority)

TSA时间戳机构(TimeStampAuthority)

TSP可信服务提供者(TrustedServiceProvider)

CMS加密消息语法(CryptographicMessageSyntax)

ESS增强安全服务(EnhancedSecurityServices)

5电子签名组成

5.1电子签名的主要参与方

电子签名在其产生和使用的过程中，要涉及多方面的机构和角色，下面列出了本标准定义的四个电

子签名主要参与方：

a)签名者。签名者是指创建电子签名的实体，当签名者使用预定义的格式对数据进行数字签名

时，就代表了它对被签名数据的一种承诺。

b)验证者。验证者是指对电子签名进行合法性验证的实体，它可以是单个实体，也可以是多个

实体。

c)可信服务提供者(TSP)。可信服务提供者是指帮助签名者和验证者建立信任关系的一个或多

个实体。它们为签名者和验证者提供了建立信任关系的可信服务，例如证书、交叉证书、时间

戳、证书撤销列表、在线证书查询等等。以下列表列出了一些主要的TSP：

1)认证机构(CA),为用户提供公钥证书；

2)注册机构(RA),在CA给用户颁发证书前，对用户进行认证和注册；

3)时间戳机构(TSA),证明数据在某个确定时间前产生；

d)仲裁者。仲裁者是指在签名者和验证者之间发生争论时，进行裁决的实体。

5.2电子签名的类型

5.2.1基本电子签名(BES)

基本电子签名(BES)是指包括了签名的基本数据信息的电子签名，这些基本数据信息主要包括以

下3项：

a)签名策略。签名策略定义了在电子签名产生和验证过程中的技术和程序要求，目的是为了满

足特定场合的需要。电子签名的参与者应识别其策略,并满足策略的要求。

b)数字签名。数字签名是签名者对以下各项信息的综合数据进行的数字签名，信息主要包括：

2

GB/T25064—2010

被签名数据的杂凑值;签名策略标识符;其他签名属性。

c)签名者提供的其他签名属性。其他签名属性是签名者为了满足签名策略要求或者标准要求而

提供的其他属性信息。

BES的基本组成结构如图1所示：

图1BES组成结构

5.2.2验证数据

根据电子签名所使用的不同策略，签名者应收集不同的验证数据添加到电子签名中，验证者同样也

需要收集与之相联系的验证信息。这些验证数据类型包括：

a)数字证书；

b)证书撤销信息，如证书撤销列表或在线查询的证书状态信息等；

c)时间戳或其他可以用来证明事件发生时间的数据，但作为最小要求，签名者和验证者获得的时

间戳必须能够维持完整性,对其的任何修改都可以被检测出来，使得各个参与方都能获得电子

签名的准确产生时间。

根据电子签名中添加的验证信息的类型和数量，电子签名的安全强度也可以得到不同程度的加强，

根据这些验证数据，电子签名可以分为多种类型。

5.2.3带验证数据的电子签名

5.2.3.1分类总述

电子签名可以有以下5种格式类型：

a)基本电子签名(BES),这类电子签名主要包含数字签名和其他签名者提供的基本信息。

b)带时间戳的电子签名(ES-T),这类电子签名在基本电子签名的基础上添加了时间戳，其目的

是保证一定程度的长时间的有效性，

c)带完全验证数据的电子签名(ES-C),这类电子签名在ES-T的基础上，添加了一套完整的用来

验证电子签名的数据，例如证书撒销参考信息等等。但其中可能包括了一些参考信息，如一个

网址，需要验证者去该网址获得具体数据。

d)带扩展的验证数据的电子签名(ES-X),这类电子签名在ES-C的基础上，添加了一些额外数

据，以适应一些特殊情况。

e)带归档时间戳的电子签名(ES-A),这类电子签名是在上述各种电子签名基础上形成的，主要

是为长期归档保存电子签名，所以对整个电子签名添加时间戳，以保证长期安全性。

签名者在提交电子签名时，至少应给出BES格式的签名，在某些情况下可以决定是否提供ES-T格

式的电子签名，在某些极端情况下可以提供ES-C格式的电子签名。如果签名者没有提供ES-T,则验

证者可在收到电子签名时立即自行创建一个ES-T,或者保存一个接收签名时间的安全记录。验证者的

这二种方法都可以为验证时间提供一个独立的证据，而验证时间实际上应接近电子签名的创建时间，使

得其可以有足够证据来防止对签名的否认。如果签名者没有提供ES-C,验证者可在BES基础上自行

创建一个ES-C,前提是其可以获得相应的验证数据。除此三种外,ES-X和ES-A均为可选支持格式。

5.2.3.2带时间戳的电子签名(ES-T)

E&T中的时间戳所记录的时间应尽可能地接近BES的实际创建时间，以提供最大程度的安全保护。

如果签名者没有提供ES-T,则验证者可在收到电子签名时立即自行创建一个ES-T。

3

GB/T25064—2010

ES-T的基本组成结构如图2所示:

图2ES-T组成结构

需要注意，当某些验证数据的安全性受到威胁的时候，数字签名上的时间戳或者一个安全的时间记

录都可以帮助保护签名的有效性，只要这些安全性威胁是在签名产生以后发生的。因为时间戳和安全

时间记录可以有效证明一份电子签名是在这些安全威胁产生前创建的，所以这份电子签名就仍然可以

保持其有效性。

5.2.3.3带完全验证数据的电子签名(ES-C)

ES-C格式的电子签名不容易与BES同时被创建，因为签名者需要去收集相关的证书信息和证书

撤销信息。如果发现一份证书已经被暂停使用，则必须等待到证书暂停期结束。从BES被创建到ES-

C被创建可能需要等待一段足够长的时间，签名者只有满足上述这种情况才能创建一个完整的ES-C。

这样带来的好处是验证者可以获得完整的用来验证BES的的数据支持。

如果签名者没有提供ES-C,验证者可在BES基础上自行创建一个ES-C,前提是其可以获得相应

的验证数据。

ES-C的基本组成结构如图3所示：

參寸劝a

图3ES-C组成结构

这里所提到的证书和证书撤销参考信息，是指验证者可以根据这些参考信息，通过指定的途径获得

最终需要的证书和证书撤销信息。

如果在实际应用中，不需要对数字签名加盖时间戳，则可以使用下面图4的ES-C1组成结构。但

是，这种情况下应保存验证时间的一个安全记录。

图4ES-C1组成结构

4

GB/T25064—2010

5.2.3.4带扩展验证数据的电子签名（ES-X）

5.2.3.3所描述的ES-C可以扩展成一种新的ES-X格式，其目的是为了适应以下需求：

a）如果验证者无法从其他途径获得以下数据，则这些数据可以被添加进电子签名，这种扩展格式

称为扩展长验证数据ES-X0格式（图5）：

1）签名者的证书；

2）构成CA证书链所需要的CA证书；

3）需要的具体证书撤销信息。

b）如果CA证书链中的任意一个CA密钥的安全性可能受到威胁，就有必要添加一个额外的时

间戳，统称为扩展时间戳验证数据。这种情况可以使用下面两种格式：

1）在ES-C的基础上，为整个ES-C产生一个时间戳，并添加到电子签名中。这种扩展格式

称为ES-X1格式（图6）；

2）在ES-C的基础上，仅仅对ES-C添加的“证书和证书撤销参考信息”产生时间戳，并添加

到电子签名中。这种扩展格式称为ES-X2格式（图7）。

c）如果以上二种情况同时发生，则需要同时在电子签名中添加二类数据。根据b）中的不同格

式，可以产生ES-X3格式（图8）和ES-X4格式（图9），统称为扩展时间戳长验证数据。

本标准定义的各种ES-X格式仅为可选格式,是否对其支持也是可选的。

ES-X0的组成结构如图5所示：

图6ES-X1组成结构

5

GB/T25064—2010

ES-X2的组成结构如图7所示:

ES-X3所包含的内容包括完整的证书和证书撤销数据，以及针对所有内容的时间戳，其基本结构如

图8所示：

LVX

BFS1的处fffill折

iF

处・的诞wMJ

函［H丽M

仿

tf

■第參写■MU

«

戟

图8ES-X3组成结构

ES-X4所包含的内容主要有完整的证书和证书撤销数据，以及对“完整的证书和证书撤销数据”上

的时间戳,其基本组成结构如图9所示：

IS-X4

ES-C—.

让丸

«•«

命

的知的巧芳

H

龙第的irfK为iF

|单九馆昭|II1&7IIt字寒MMln•

d

W"/IX

媲的

你吹秤tunkttM

上

位0KH

Ad

图9ES-X4组成结构

5.2.3.5带归档时间戳的电子签名(ES-A)

各种算法、密钥、加密数据、加密函数都会随着时间而逐渐降低其安全性，各种证书也会随着时间而

纷纷失效，如果要长期保存一个电子签名，就需要在这些成分的安全性降低前对整个电子签名加盖一次

时间戳。新加的时间戳尽可能使用比老时间戳更强的算法和密钥。这类额外添加的验证数据称为归档

验证数据。

考虑到时间戳所使用的证书、算法和密钥也会随着时间而失效或降低安全性，在这种情况发生前,

必须加盖新的时间戳。因此，一个ES-A可能嵌套了多重时间戳。

本标准定义的ES-A是可选格式，对其的支持也是可选的。

6

GB/T25064—2010

ES-A的基本组成结构如图10所示:

E&A

inhrt

pi*

图10ES-A基本结构

5.3电子签名的验证

5.3.1验证目标

对电子签名的验证必须符合电子签名策略，验证的结果有3种情况：

a）签名有效。这个结果意味着该电子签名通过了验证，并且符合电子签名策略的所有要求；

b）签名无效。签名无效基于以下二种情况：

1）电子签名的格式错误；

2）数字签名验证失败，例如：数字签名完整性检测失败；验证过程中所使用的数字证书已经

无效或者被撤销；

c）不完全验证。这个结果意味着电子签名的格式没有错误，数字签名也已经通过验证，但是没有

足够的信息判断该电子签名是否符合其签名策略的要求。例如，签名策略需要一些附加信息，

这些信息对数字签名的有效性没有任何影响，但是现在因为无法获得，所以无法判断是否符合

签名策略。在这种情况下，验证者应根据策略要求用户自行处理“部分正确”的电子签名，也可

在信息足够时再度对电子签名进行验证。

5.3.2验证过程

如5.2.2所述，签名者和验证者都可以收集所有的额外数据来完成一个电子签名的创建和验证，图

11描述了如何完成一个ES-C验证的过程。

图11ES-C的验证过程

7

GB/T25064—2010

a）在收到签名者的BES以后，验证者根据被签名数据和BES,首先验证数字签名的正确性、完整

性和有效性。

b）验证者根据电子签名以及TSP提供的数据，检查签名是否符合签名策略的要求。

c）如果签名者没有提供时间戳或者没有提供可以信任的时间戳，则验证者此时应自行添加一个

时间戳。因此到这一步截止，至少应产生一个ES-T电子签名。

d）如果签名者没有提供证书和证书撤销参考信息，则验证者需要收集所有必需的证书和证书撤

销信息，并在这些数据可以使用后，完成所有的验证过程。然后记录一个完整的证书和证书撤

销参考信息，创建ES-C电子签名。

e）验证者输出验证结果。

ES-C是标准中必须支持的格式，但是验证者可以进一步扩展成需要的ES-X或者ES-A可选

格式。

如果签名者没有提供ES-X,则在验证者完成ES-C以后，验证者将可以提供或记录在ES-C中

使用的完整的证书和证书撤销数据（图12中的步骤f））,从而形成ES-XO格式，过程如图12

所示：

tts-xu

IIw?I

■

負if畐■Lft

散範

■不兗全•if

mm*

图12验证者创建ES-X0

根据验证者的选择和实际情况，也可以创建一个ES-X1电子签名，在整个ES-C上加盖时间戳（图

13中步骤g））,过程如图13所示：

8

GB/T25064—2010

验证者也可以创建一个ES-X2电子签名，只在“证书和证书撤销参考信息”上加盖时间戳（图14中

步骤g'））,过程如图14所示：

Al/dlsS**

■AA

■L*

9M

■平完全ikif

am#

图14验证者创建ES-X2

最后，验证者有必要针对需要长期保存的电子签名创建ES-A格式，这种格式不需要马上创建，但

应在电子签名中任何一项元素（如算法、密钥、证书等）的安全性受威胁前创建。创建时，验证者需要针

对整个电子签名的所有内容加盖时间戳（图15中步骤h））,过程如图15所示：

9

GB/T25064—2010

图15验证者创建ES-A

5.3.3仲裁

如果签名者和验证者发生争执，则需要提请仲裁者进行仲裁。针对提请仲裁的电子签名类型，有以

下这些考虑：

ES-C签名可以作为仲裁使用的签名类型，但必须符合下面3个条件：

a）仲裁者知道如何获得签名者的证书、所有的交叉认证证书、需要的CRL以及ES-C可能提到

的OCSP查询；

b）签名所使用的整个证书链都是安全的，链上每个证书密钥的安全性都还未受到威胁；

c）在ES-C创建时所使用的各种密码学技术，在仲裁时仍然是安全的。

如果条件a）不满足，则原告方需要提供ES-XO电子签名。

如果条件b）不满足，则原告方需要提供ES-X1或者ES-X2电子签名。

如果条件c）不满足，则原告方需要提供ES-A电子签名。

6电子签名的数据格式

6.1基本数据格式

本标准中数据格式、语法结构等均采用GB/T16262.1—2006规定的ASN.1表示描述。本条中的

数据格式定义以RFCZ630中矩义的加密消息语法（CMS）和RFC2634中定义的增强安全服务（ESS）为

基础。对于RFC2630和RFC2634中已定义的语法结构，本标准直接引用不再给出具体定义。

6.1.1总体语法结构

电子签名的总体语法结构见RFC2630中的定义。

6.1.2数据内容类型

电子签名中的数据内容类型的语法结构和要求见RFC2630。

6.1.3签名数据内容类型

电子签名中的签名数据内容类型的语法结构和要求见RFC2630o

为了确保签名验证方能够正确地使用签名者公钥进行验证，本标准中规定，签名证书属性（Signed

10

GB/T25064—2010

Attribute)应包含签名者的签名认证证书的杂凑值，签名证书属性的定义见RFC2634。

6.1.4签名数据类型

电子签名中的签名数据类型的语法结构和要求除了符合RFC263O的规定外，还应满足以下3点：

a)版本号须设置为3；

b)用于签名的签名者证书的标识须经过签名；

c)签名数据中必须至少有一个签名者信息。

6.1.5封装数据内容信息类型

电子签名中的封装数据内容信息类型的语法结构和要求见RFC263O。其中各字段的含义和要求

与RFC263O中一致，另外还要求字段中必须至少有一个签名者信息。

6.1.6签名者信息类型

电子签名中的签名者信息类型的语法结构和要求见RFC2630o每个签名者的信息都用一个签名

者信息类型的数据结构表示，对有多个独立签名者的情况，每个签名者都使用一个签名者信息类型的数

据结构表示。

签名者信息类型中各字段的含义和要求与RFC2630中相同，但被签名属性中须包含以下属性：

a)内容类型；

b)消息摘要；

c)签名时间；

d)签名证书；

e)签名策略标识。

其消息摘要的计算流程、消息签名的生成流程见RFC2630中的相关规定。消息签名的验证流程除

了RFC263O中规定的内容外，还应满足以下要求：

用于验证签名的签名者的公钥的真实性须使用ESS规定的或其他的签名证书属性来验证。

6.1.7RFC2630中引入的强制属性

在本标准所规定的电子签名中，下列几种RFC2630中定义的属性必须与签名数据一同出现：

a)内容类型属性(content-typeattribute),其语法结构定义见RFC2630；

b)消息摘要属性(message-digestattribute),其语法结构定义见RFC2630；

c)签名时间属性(signing-timeattribute),其语法结构定义见RFC2630。该属性中的时间值应是

签名者声称已经完成签名过程的时间，本标准中建议时间格式采用GeneralizedTime类型。

6.1.8可替代的签名证书属性

6.1.8.1签名证书属性选择标准

符合本标准的电子签名应在签名数据中包含下面两个可选签名证书属性中的一个，而且仅包含一

个。选择的依据是：当使用的杂凑函数为SHA-1时使用ESS签名证书属性，当使用其他杂凑函数时，

使用其他签名证书属性。

6.1.8.2ESS签名证书属性

ESS签名证书属性的语法结构定义和要求见RFC2634。各字段的含义和用法除了RFC2634中规

定的以外还须满足以下几点：

a)ESS签名证书属性必须是被签名属性，而且不能为空。用于验证签名的证书的标识必须包含

在该属性中。

b)用于验证签名的证书所对应的ESS签名证书属性中ESSCertID字段的编码应包含

issureSerial字段，而且issureSerial字段内容应该与Signerinfo中的issuerAndSerialNumber

字段内容相符。在签名验证过程中,应检查所使用的验证证书的杂凑值与上述字段中的相应

内容是否一致，如不一致,应认定该签名无效。

11

GB/T25064—2010

6.1.8.3其他签名证书属性

该属性的结构与ESS签名证书属性相同，但该属性可以在杂凑函数非SHA-1的情况下使用。对

ESS签名证书属性的使用要求同样适用于该属性。

该属性的对象标识符(OID,0bjectIdentifier)如下：

id-aa-ets-otherSigCertOBJECTIDENTIFIER::={iso(1)member-body(2)us(840)rsadsi

(113549)pkcs(l)pkcs9(9)smime(16)id-aa(2)19}

该属性(OtherSigningCertificate)的语法结构ASN.1描述如下：

OtherSigningCertificate::=SEQUENCE{

certsSEQUENCEOFOtherCerllD,

}

OtherCertID::=SEQUENCE{

otherCertHashOtherHash,

issuerSerialIssuerSerialOPTIONAL}

OtherHash::=CHOICE{

shalHashOtherHashValue,-该字段包含一个SHA-1的杂凑值

otherHashOtherHashAlgAndValue}

OtherHashValue::=OCTETSTRING

OtherHashAlgAndValue::=SEQUENCE{

hashAlgorithmAlgorithmidentifier,

hashValueOtherHashValue}

6.1.9其他强制属性

本标准要求在签名数据(SignedData)中必须包含一个对签名策略的引用。这个引用可以被显式地

标识出来，也可以是通过签名内容或其他外部数据隐式的给出.签名策略定义了产牛并验证一个签名

的规则，应在每个签名的被签名属性中都包含。签名策略标识属性应为被签名属性＜签名策略标识的

对象标识符为：

id-aa-ets-sigPolicyldOBJECTIDENTIFIER::={iso(1)member-body(2)us(840)rsadsi

(113549)pkcs(l)pkcs9(9)smime(16)id-aa(2)15}

其语法结构的ASN.1描述为：

Signature-policy-identifierattributevalueshaveASN.1typeSignaturePolicyldcntifier.

SignaturcPolicyldentifier::=CHOICE{

SignaturePolicyldSignaturePolicyld,

SignaturePolicylmplicdSignaturePolicylmplicd}

SignaturePolicyld::=SEQUENCE{

sigPolicyldSigPolicyld,

sigPolicyHashSigPolicyHash,

sigPolicyQualifiersSEQUENCESIZE(1..MAX)OFSigPolicyQualifierlnfo

OPTIONAL}

SignaturePolicylmplicd::—NULL

SignaturePolicylmplied为NULL类型表明了，签名策略是在签名内容或其他外部数据中隐式的给

出的。

SigPolicyld字段包含了一个能够唯一标识某个签名策略的对象标识符，其语法结构为：

SigPolicyld::=OBJECTIDENTIFIER

SigPolicyHash字段包含了杂凑算法的标识符和对签名策略的杂凑运算结果。

12

GB/T25064—2010

如果签名策略是用ASN.1定义的，则其杂凑值是对其编码中除去外部类型和长度的部分做杂凑

运算的结果，而且杂凑函数算法应在SignPolicyHshAlg字段中给出。

如果签名策略是用其他语法结构定义的,则其语法结构的类型以及使用的杂凑函数应作为签名策

略的一部分给出，或使用签名策略限定符(signaturepolicyqualifier)标明。

SigPolicyHash::=OtherHashAlgAndValue

签名策略标识符应通过签名策略限定符的其他相关信息限定。签名策略限定符的语义及语法结构

是与SigPolicyQualifierld字段中的对象标识符相关联的，其语法定义如下：

SigPolicyQualifierlnfo::=SEQUENCE{

SigPolicyQualifierldSigPolicyQualifierld,

sigQualifierANYDEFINEDBYSigPolicyQualifierld}

本标准给出两种限定符：

a)spuri：包含了指向签名策略的URI或URL；

b)spUserNotice：包含一个用户通知，当验证签名时该通知应被显示给验证者。

SigPolicyQualifierld::=OBJECTIDENTIFIER

id-spq-ets-uriOBJECTIDENTIFIER::={iso(1)member-body(2)us(840)rsadsi(113549)

pkcs(l)pkcs9(9)smime(16)id-spq(5)1}

SPuri::—IA5String

id-spq-ets-unoticeOBJECTIDENTIFIER::={iso(1)member-body(2)us(840)rsadsi

(113549)pkcs(l)pkcs9(9)smime(16)id-spq(5)2}

SPUserNotice::=SEQUENCE{

noticcRefNoticcReferenceOPTIONAL,

explicitTextDisplayTextOPTIONAL}

NoticcReference::=SEQUENCE{

organizationDisplayText,

noticeNumbcrsSEQUENCEOFINTEGER}

DisplayText::=CHOI