标准搜索结果: 'GB/T 25064-2010'
| 标准编号 | GB/T 25064-2010 (GB/T25064-2010) | | 中文名称 | 信息安全技术 公钥基础设施 电子签名格式规范 | | 英文名称 | Information security technology. Public key infrastructure. Electronic signature formats specification | | 行业 | 国家标准 (推荐) | | 中标分类 | L80 | | 国际标准分类 | 35.040 | | 字数估计 | 44,477 | | 发布日期 | 2010-09-02 | | 实施日期 | 2011-02-01 | | 引用标准 | GB/T 16264.8-2005; GB/T 16262.1-2006; GB/T 19713-2005; GB/T 20518-2006; GB/T 20520-2006; RFC2630; RFC2634 | | 起草单位 | 中国科学院软件研究所信息安全国家重点实验室 | | 归口单位 | 全国信息安全标准化技术委员会 | | 标准依据 | 国家标准批准发布公告2010年第4号(总第159号) | | 提出机构 | National Safety Standardization Technical Committee (SAC/TC 260) | | 发布机构 | Administration of Quality Supervision, Inspection and Quarantine of People's Republic of China; Standardization Administration of China | | 范围 | 本标准针对基于公钥密码学生成的数字签名类型的电子签名, 定义了电子签名与验证的主要参与方、电子签名的类型、验证和仲裁要求;本标准还规范了电子签名的数据格式, 包括基本数据格式, 验证数据格式、签名策略格式等;本标准适用于电子签名产品的设计和实现, 同时相关产品的测试、评估和采购亦可参照使用; | GB/T 25064-2010
L80
中华人民共和国国家标准
信息安全技术 公钥基础设施
电子签名格式规范
2010-09-02发布
2011-02-01实施
中华人民共和国国家质量监督检验检疫总局
中国国家标准化管理委员会发布
目次
前言 Ⅰ
引言 Ⅱ
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
前言
本标准的附录A和附录B为规范性附录。
本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口。
本标准起草单位:中国科学院软件研究所信息安全国家重点实验室、信息安全共性技术国家工程研
究中心。
本标准主要起草人:张凡、冯登国、庄涌、张立武、路晓明、杨婧。
引 言
电子商务作为跨越本地、广域、全球网络的新型商务模式,可信对于其成功和连续进行至关重要。
以电子方式进行商务活动的公司必须有适合的安全控制机制来保护他们的交易并确保交易方的安全,
而电子签名对于保护信息和提供电子商务中的信任是一项重要的安全措施。
的电子签名,可以应用于各种业务,包括个人与公司、公司与公司、个人与政府。本标准独立于应用环
境,可以应用在智能卡、GSMSIM卡、电子签名的特殊应用等各种环境中。根据本标准生成的电子签
名并满足《中华人民共和国电子签名法》第十三条规定,即认为是可靠的电子签名。
本标准凡涉及密码算法相关内容,按国家密码管理部门相关规定执行。
本标准例子中提及的密码算法如SHA-1算法均为举例性说明,具体使用时均须采用国家密码管理
部门批准的相应算法。
信息安全技术 公钥基础设施
电子签名格式规范
1 范围
本标准针对基于公钥密码学生成的数字签名类型的电子签名,定义了电子签名与验证的主要参与
方、电子签名的类型、验证和仲裁要求。本标准还规范了电子签名的数据格式,包括基本数据格式、验证
数据格式、签名策略格式等。
本标准适用于电子签名产品的设计和实现,同时相关产品的测试、评估和采购亦可参照使用。
2 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有
的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究
是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
GB/T 16264.8-2005 信息技术 开放系统互连 目录 第8部分:公钥和属性证书框架(ISO/
IEC 9594-8:2001,IDT)
GB/T 16262.1-2006 信息技术 抽象语法记法一(ASN.1) 第1部分:基本记法规范(ISO/
IEC 8824-1:2002,IDT)
GB/T 19713-2005 信息技术 安全技术 公钥基础设施 在线证书状态协议
GB/T 20518-2006 信息安全技术 公钥基础设施 数字证书格式
GB/T 20520-2006 信息安全技术 公钥基础设施 时间戳规范
RFC2630 加密消息语法
RFC2634 S/MIME的增强安全服务
3 术语和定义
下列术语和定义适用于本标准。
3.1
签名者 signer
电子签名人,创建电子签名的实体。
3.2
验证者 verifier
电子签名依赖方,对电子签名进行合法性验证的实体。
3.3
仲裁者 arbitrator
当数字签名的有效性发生争议时,对签名者和验证者之间的争议进行仲裁的实体。
3.4
帮助签名者和验证者建立信任关系的一个或多个实体。
3.5
时间戳 timestamp
使用数字签名技术产生的数据,签名的对象包括了原始文件信息、签名参数、签名时间等信息。时
间戳机构对此对象进行数字签名产生时间戳,以证明原始文件在签名时间之前已经存在。
3.6
签名策略 signaturepolicy
创建和验证电子签名的一套规则,可以在签名策略的指导下决定一个电子签名是否合法。
4 缩略语
下列缩略语适用于本标准:
ES-T 带时间戳的电子签名(ESwithTimestamp)
TSA 时间戳机构(TimeStampAuthority)
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) 数字签名。数字签名是签名者对以下各项信息的综合数据进行的数字签名,信息主要包括:
被签名数据的杂凑值;签名策略标识符;其他签名属性。
c) 签名者提供的其他签名属性。其他签名属性是签名者为了满足签名策略要求或者标准要求而
提供的其他属性信息。
BES的基本组成结构如图1所示:
图1 BES组成结构
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)
ES-T中的时间戳所记录的时间应尽可能地接近BES的实际创建时间,以提供最大程度的安全保护。
如果签名者没有提供ES-T,则验证者可在收到电子签名时立即自行创建一个ES-T。
ES-T的基本组成结构如图2所示:
图2 ES-T组成结构
需要注意,当某些验证数据的安全性受到威胁的时候,数字签名上的时间戳或者一个安全的时间记
录都可以帮助保护签名的有效性,只要这些安全性威胁是在签名产生以后发生的。因为时间戳和安全
时间记录可以有效证明一份电子签名是在这些安全威胁产生前创建的,所以这份电子签名就仍然可以
保持其有效性。
5.2.3.3 带完全验证数据的电子签名(ES-C)
ES-C格式的电子签名不容易与BES同时被创建,因为签名者需要去收集相关的证书信息和证书
撤销信息。如果发现一份证书已经被暂停使用,则必须等待到证书暂停期结束。从BES被创建到ES-
C被创建可能需要等待一段足够长的时间,签名者只有满足上述这种情况才能创建一个完整的ES-C。
这样带来的好处是验证者可以获得完整的用来验证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-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所示:
图5 ES-X0组成结构
ES-X1的组成结构如图6所示:
图6 ES-X1组成结构
ES-X2的组成结构如图7所示:
图7 ES-X2组成结构
ES-X3所包含的内容包括完整的证书和证书撤销数据,以及针对所有内容的时间戳,其基本结构如
图8所示:
图8 ES-X3组成结构
ES-X4所包含的内容主要有完整的证书和证书撤销数据,以及对“完整的证书和证书撤销数据”上
的时间戳,其基本组成结构如图9所示:
图9 ES-X4组成结构
5.2.3.5 带归档时间戳的电子签名(ES-A)
各种算法、密钥、加密数据、加密函数都会随着时间而逐渐降低其安全性,各种证书也会随着时间而
纷纷失效,如果要长期保存一个电子签名,就需要在这些成分的安全性降低前对整个电子签名加盖一次
时间戳。新加的时间戳尽可能使用比老时间戳更强的算法和密钥。这类额外添加的验证数据称为归档
验证数据。
考虑到时间戳所使用的证书、算法和密钥也会随着时间而失效或降低安全性,在这种情况发生前,
必须加盖新的时间戳。因此,一个ES-A可能嵌套了多重时间戳。
本标准定义的ES-A是可选格式,对其的支持也是可选的。
ES-A的基本组成结构如图10所示:
图10 ES-A基本结构
5.3 电子签名的验证
5.3.1 验证目标
对电子签名的验证必须符合电子签名策略,验证的结果有3种情况:
a) 签名有效。这个结果意味着该电子签名通过了验证,并且符合电子签名策略的所有要求;
b) 签名无效。签名无效基于以下二种情况:
1) 电子签名的格式错误;
2) 数字签名验证失败,例如:数字签名完整性检测失败;验证过程中所使用的数字证书已经
无效或者被撤销;
c) 不完全验证。这个结果意味着电子签名的格式没有错误,数字签名也已经通过验证,但是没有
足够的信息判断该电子签名是否符合其签名策略的要求。例如,签名策略需要一些附加信息,
这些信息对数字签名的有效性没有任何影响,但是现在因为无法获得,所以无法判断是否符合
签名策略。在这种情况下,验证者应根据策略要求用户自行处理“部分正确”的电子签名,也可
在信息足够时再度对电子签名进行验证。
5.3.2 验证过程
如5.2.2所述,签名者和验证者都可以收集所有的额外数据来完成一个电子签名的创建和验证,图
11描述了如何完成一个ES-C验证的过程。
图11 ES-C的验证过程
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-X0格式,过程如图12
所示:
图12 验证者创建ES-X0
根据验证者的选择和实际情况,也可以创建一个ES-X1电子签名,在整个ES-C上加盖时间戳(图
13中步骤g)),过程如图13所示:
图13 验证者创建ES-X1
验证者也可以创建一个ES-X2电子签名,只在“证书和证书撤销参考信息”上加盖时间戳(图14中
步骤g′)),过程如图14所示:
图14 验证者创建ES-X2
最后,验证者有必要针对需要长期保存的电子签名创建ES-A格式,这种格式不需要马上创建,但
应在电子签名中任何一项元素(如算法、密钥、证书等)的安全性受威胁前创建。创建时,验证者需要针
对整个电子签名的所有内容加盖时间戳(图15中步骤h)),过程如图15所示:
图15 验证者创建ES-A
5.3.3 仲裁
如果签名者和验证者发生争执,则需要提请仲裁者进行仲裁。针对提请仲裁的电子签名类型,有以
下这些考虑:
ES-C签名可以作为仲裁使用的签名类型,但必须符合下面3个条件:
a) 仲裁者知道如何获得签名者的证书、所有的交叉认证证书、需要的CRL以及ES-C可能提到
的OCSP查询;
b) 签名所使用的整个证书链都是安全的,链上每个证书密钥的安全性都还未受到威胁;
c) 在ES-C创建时所使用的各种密码学技术,在仲裁时仍然是安全的。
如果条件a)不满足,则原告方需要提供ES-X0电子签名。
如果条件b)不满足,则原告方需要提供ES-X1或者ES-X2电子签名。
如果条件c)不满足,则原告方需要提供ES-A电子签名。
6 电子签名的数据格式
6.1 基本数据格式
本标准中数据格式、语法结构等均采用GB/T 16262.1-2006规定的ASN.1表示描述。本条中的
数据格式定义以RFC2630中定义的加密消息语法(CMS)和RFC2634中定义的增强安全服务(ESS)为
基础。对于RFC2630和RFC2634中已定义的语法结构,本标准直接引用不再给出具体定义。
6.1.1 总体语法结构
电子签名的总体语法结构见RFC2630中的定义。
6.1.2 数据内容类型
电子签名中的数据内容类型的语法结构和要求见RFC2630。
6.1.3 签名数据内容类型
电子签名中的签名数据内容类型的语法结构和要求见RFC2630。
为了确保签名验证方能够正确地使用签名者公钥进行验证,本标准中规定,签名证书属性(Signed
Attribute)应包含签名者的签名认证证书的杂凑值,签名证书属性的定义见RFC2634。
6.1.4 签名数据类型
电子签名中的签名数据类型的语法结构和要求除了符合RFC2630的规定外,还应满足以下3点:
a) 版本号须设置为3;
b) 用于签名的签名者证书的标识须经过签名;
c) 签名数据中必须至少有一个签名者信息。
6.1.5 封装数据内容信息......
|