搜索结果: GB/T 19771-2025, GB/T19771-2025, GBT 19771-2025, GBT19771-2025
| 标准编号 | GB/T 19771-2025 (GB/T19771-2025) | | 中文名称 | 网络安全技术 公钥基础设施 PKI组件最小互操作规范 | | 英文名称 | Cybersecurity technology - Public key infrastructure - Specification for minimum interoperability for PKI components | | 行业 | 国家标准 (推荐) | | 中标分类 | L80 | | 国际标准分类 | 35.030 | | 字数估计 | 22,250 | | 发布日期 | 2025-08-01 | | 实施日期 | 2026-02-01 | | 旧标准 (被替代) | GB/T 19771-2005 | | 发布机构 | 国家市场监督管理总局、国家标准化管理委员会 | GB/T 19771-2025: 网络安全技术 公钥基础设施 PKI组件最小互操作规范
ICS 35.030
CCSL80
中华人民共和国国家标准
代替GB/T 19771-2005
网络安全技术 公钥基础设施
PKI组件最小互操作规范
2025-08-01发布
2026-02-01实施
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会 发 布
目次
前言 Ⅲ
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 缩略语 2
5 最小互操作基本功能要求 3
5.1 概述 3
5.2 CA系统 3
5.3 RA系统 4
5.4 证书持有者 5
5.5 证书验证者 5
5.6 密码算法 6
6 互操作事务数据格式要求 6
6.1 总体要求 6
6.2 注册请求 6
6.3 证书密钥更新 10
6.4 撤销请求 11
6.5 访问资料库 13
7 测试评价方法 13
7.1 通用测试评价方法 13
7.2 最小互操作基本功能测试评价方法 13
7.3 互操作数据格式测试评价方法 15
前言
本文件按照GB/T 1.1-2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
本文件代替GB/T 19771-2005《信息技术 安全技术 公钥基础设施PKI组件最小互操作规
范》,与GB/T 19771-2005相比,除结构调整和编辑性改动外,主要技术变化如下:
a) 更改了“范围”的内容,重新界定了文件的标准化对象和所覆盖的各个方面,并更改了文件的适
用界限(见第1章,2005年版的第1章);
b) 更改了PKI四个组件的基本功能要求(见第5章,2005年版的第5章),增加了对BYOD请求
证书的功能要求(见5.3.2、5.4.2),增加了验证证书的最小步骤要求(见5.2.2),增加了对商用
密码算法的支持(见5.6);
c) 更改了互操作事务数据格式的要求,将对数字证书的数据结构、证书扩展、证书撤销列表的格
式要求修改为符合GB/T 20518-2018(见6.1,2005年版的6.1、6.2、6.3);将对PKI事务消息
格式的内容的要求修改为符合GB/T 19714-2025(见6.1,2005年版的6.5);更改了PKI事务
的消息内容(见第6章,2005年版的6.6);
d) 增加了对CA系统、RA系统、证书持有者、证书验证者功能的测试评价方法,增加了互操作数
据格式测试评价方法(见第7章);
e) 删除了规范性附录A、规范性附录B、规范性附录C、规范性附录D(见2005版的附录A、附录
B、附录C、附录D)。
本文件由全国网络安全标准化技术委员会(SAC/TC260)提出并归口。
本文件起草单位:中国科学院大学、北京数字认证股份有限公司、公安部第三研究所、中国科学院软
件研究所、长春吉大正元信息技术股份有限公司、安徽信科共创信息安全测评有限公司、清华大学、广东
省电子商务认证有限公司、深圳市电子商务安全证书管理有限公司、亚数信息科技(上海)有限公司、
中科信息安全共性技术国家工程研究中心有限公司、联通在线信息科技有限公司、北京中关村实验室、
奇安信网神信息技术(北京)股份有限公司、陕西省信息化工程研究院、国家信息技术安全研究中心、
中孚信息股份有限公司、杭州海康威视数字技术股份有限公司、中国电子信息产业集团有限公司第六研
究所、长扬科技(北京)股份有限公司。
本文件主要起草人:冯登国、荆继武、刘丽敏、郑亚杰、陈妍、丁肇伟、张建国、寇春静、张立武、
贾珂婷、张严、秦岭月、李强、陈树乐、郑会涛、魏一才、胡建勋、梁斌、赵博鑫、孟佳颖、安锦程、赵晓荣、
梁利、陈腾、王滨、王龙、赵华。
本文件及其所代替文件的历次版本发布情况为:
---2005年首次发布为GB/T 19771-2005;
---本次为第一次修订。
网络安全技术 公钥基础设施
PKI组件最小互操作规范
1 范围
本文件规定了公钥基础设施组件最小互操作的基本功能要求和数据格式要求,描述了测试评价
方法。
本文件适用于电子签名、电子签章、身份管理等活动中PKI的设计、开发、测试及其应用。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文
件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于
本文件。
GB/T 15852.2 网络安全技术 消息鉴别码 第2部分:采用专门设计的杂凑函数的机制
GB/T 19714-2025 网络安全技术 公钥基础设施 证书管理协议
GB/T 20518-2018 信息安全技术 公钥基础设施 数字证书格式
GB/T 25056-2018 信息安全技术 证书认证系统密码及其相关安全技术规范
GB/T 32905 信息安全技术 SM3密码杂凑算法
GB/T 32907 信息安全技术 SM4分组密码算法
GB/T 32918.2 信息安全技术 SM2椭圆曲线公钥密码算法 第2部分:数字签名算法
GB/T 37092 信息安全技术 密码模块安全要求
GB/T 43694 网络安全技术 证书应用综合服务接口规范
GM/Z0001-2013 密码术语
3 术语和定义
GB/T 25056-2018、GM/Z0001-2013界定的以及下列术语和定义适用于本文件。
3.1
构成PKI系统的组成要素,用于进行证书相关活动的实体。
3.2
数字证书 digitalcertificate
由证书认证机构对用户的公钥和身份信息进行确认,并用私钥进行签名的数据。
注:也称公钥证书。
3.3
签名证书 signaturecertificate
用于证明签名公钥的数字证书。
[来源:GM/Z0001-2013,2.90]
3.4
用于证明加密公钥的数字证书。
[来源:GM/Z4001-2013,2.43,有修改]
3.5
对数字证书的签发、发布、更新、撤销等数字证书全生命周期进行管理的系统。
[来源:GM/Z4001-2013,2.146,有修改]
3.6
RA系统 registrationsystem
为用户办理证书申请、身份审核、证书下载、证书密钥更新、证书注销以及密钥恢复等实际业务的
系统。
3.7
证书持有者 certificateholder
与有效证书的主体相对应的实体。
3.8
证书验证者 certificateverifier
需要获取另一实体的公钥,并利用PKI获取证书并执行验证证书和签名功能的实体。
3.9
资料库 repository
存储数字证书和CRL等信息,并提供无需验证的信息检索服务的数据库。
3.10
证书策略 certificatepolicy
预先定义的界定证书的通用安全要求和适用范围的一组规则集。
3.11
证书认证机构签发某证书策略的证书时遵循的相关业务操作的规则。
3.12
证书认证路径 certificationpath
基于起始可信证书的有序证书序列。
注:通过处理该有序序列及其起始对象的公钥能得知该路径的末端对象的公钥。
3.13
标记一系列不再被证书发布者所信任的证书的签名列表。
[来源:GB/T 25056-2018,3.4]
4 缩略语
下列缩略语适用于本文件。
BYOD:自带设备(BringYourOwnDevice)
5.1 概述
PKI系统是通过公钥密码技术提供安全通信、身份认证和数据完整性保障的框架,包括硬件、软件
和标准化流程。PKI系统由四个需要互相通信的PKI组件构成,分别是CA系统、RA系统、证书持有
者和证书验证者。这四个组件分别提供不同的功能,但一个实体可承担多个组件的角色。一个实体可
同时承担CA系统和RA系统两个角色。证书持有者可为证书验证者,证书验证者不必为证书持有者。
互操作是PKI组件之间通过互相通信和协作,共同完成PKI功能的操作。最小互操作是PKI组
件为了实现证书注册、证书密钥更新、证书撤销、资料库访问等PKI基本功能所需要的最低限度的互操
作。最小互操作的基本功能是这些组件为了实现基本的PKI功能所应具备的互操作。
5.2 CA系统
5.2.1 总体要求
CA系统应支持以下功能:
a) 签发并传送证书给终端实体和其他的CA;
b) 接收来自RA系统的证书撤销请求;
c) 将证书和CRL存入资料库;
d) 为下级CA签发证书。
CA系统生成自己的公私钥对并公布自己的证书。CA系统可授权属于同一机构的RA系统去确
认申请证书的使用者的身份或其他的特征属性,授权通过离线接受来自某个RA系统的证书请求完成。
CA系统具备5.4中证书持有者的功能:请求、撤销、更新由其他CA系统签发的证书;也具备5.5
中证书验证者的功能:检索证书和CRL、验证证书认证路径。使用CA系统完成证书的生成和签发应
符合GB/T 25056-2018中5.3.4的要求。
5.2.2 签发签名证书
CA系统应支持两种签名证书的证书请求:RA系统发起的注册请求和自我注册请求。
根据不同类型,CA系统采用不同方式鉴别申请证书主体的身份。
a) RA系统发起的证书请求。RA系统应确保用户身份与公钥的绑定。CA系统处理来自经授权的
RA系统的证书请求。如请求被接受,CA系统生成新证书并存储在资料库中,然后将该证书发
给相应的RA或证书持有者。如请求由非经授权的RA系统发送,即签名无效或信息不匹配,CA
系统拒绝请求并向RA系统报告失败并说明原因。CA系统应至少能支持GB/T 20518-2018中
b) 自我注册请求。RA系统可为提交请求的实体提供一份秘密信息。请求实体生成公私钥对,
创建证书请求消息并使用相应私钥签名,被签名的部分可包括基于RA提供的秘密信息导出
的认证信息。CA系统接收请求,通过认证信息验证请求者身份,并确认其实体拥有私钥。若
验证成功,CA系统生成新证书并存入资料库,随后发送至证书持有者。若验证失败、签名无
效或信息不匹配,CA系统拒绝请求并向申请者报告失败原因。
5.2.3 签发加密证书
CA系统应支持实体进行加密证书的申请。CA系统处理来自授权的RA系统的加密证书的请求。
如请求被接受,CA系统响应证书申请,用户的加解密公私钥对可由第三方产生,CA系统通过安全的方
式获得加密公钥和用户加密私钥数据信封。CA系统签发加密证书并存储在资料库中,并将该证书和
加密私钥数据信封返回给相应的RA或证书持有者。
5.2.4 交叉认证
CA系统应具备向其他CA签发证书的能力。交叉认证决策通过物理形式进行,并应按照与证书
策略相关的认证业务规则进行安全可信检查。CA系统应对签发的交叉证书的路径验证做出适当约
束,应将basicConstraints设置为关键扩展并配置相应约束条件(如,路径长度的约束),宜将nameCon-
straints、policyConstraints和policyMappings设置为关键扩展并配置相应约束条件。如未设置这些扩
展或不进行路径验证约束,即允许对方CA系统无限制地进行签名传递,签发交叉证书的CA应承担其
证书策略对应的认证业务规则中承诺的全部责任,包括给其他无关CA签发的所有证书的责任。
5.2.5 证书密钥更新请求
申请者通过其原有私钥对更新请求消息进行签名以完成身份验证。CA系统处理证书密钥更新请
求,若签名有效,则签发新证书给证书持有者并存入资料库。若签名无效、请求实体处于非法状态或更
新请求不符合CA系统的认证业务规则或证书策略,CA系统拒绝该请求。
5.2.6 证书撤销
CA系统应按照相关证书策略对应的认证业务规则,按时生成和发布包含所有被撤销但尚未到期
的证书的完整证书撤销列表(CRL)。签发CRL的形式和周期由相关证书策略对应的认证业务规则
决定。
5.2.7 为下级CA签发证书
CA应能向层次更高的CA申请证书。在生成证书请求时,应使用basicConstraints扩展来明确该
请求来自一个CA实体。在签发下级CA证书时,应在证书中明确授权的证书策略、层级限制以及名称
限制。如缺少这些扩展,或者这些扩展存在但被设置为非关键项,则上级CA应对下级CA签发的所有
证书承担与证书策略对应的认证业务规则中所承诺的所有的法律责任。
5.3 RA系统
5.3.1 与互操作性有关的功能要求
RA系统应支持以下功能:
1) 接受和验证证书请求;
2) 向CA系统发送证书请求;
3) 生成证书撤销请求。
RA系统与其他组件进行互操作时,基本功能要求如下。
a) 当物理证书介质与RA系统进行物理连接时,RA系统通过验证签名消息来验证该介质中拥
有与公钥相应的私钥材料。在密钥对和实体身份均经过验证之后,RA系统签署并向相应的
CA系统发送数字证书请求。
b) 未与RA系统进行过物理接触的证书请求者,在发起证书请求时,应持有RA系统提供的认证
信息。此信息将作为实体在自我注册请求中向CA系统证明其身份的证据。
c) RA系统应支持对CA系统授权其所管理的实体证书请求进行证书撤销操作。该功能可与
CA系统集成,也可在不同的设施中执行。
d) RA系统应将新签发的证书与CA的证书一同发送给证书持有者。
e) RA系统应代表不再拥有私钥并且怀疑该私钥已泄露的证书持有者产生并签署证书撤销请
求。如果CA的认证业务规则允许,RA系统应代表证书持有者的组织产生并签署证书撤销
请求。
5.3.2 使用BYOD请求证书的RA系统功能要求
RA系统应验证BYOD设备的密码模块是否符合GB/T 37092的要求。RA应鉴别密码模块的安
全等级是否与认证业务规则一致。
5.4 证书持有者
5.4.1 与互操作性相关的功能要求
证书持有者包括CA、RA和其他的终端实体。终端实体是个人、企业、用户、计算机系统或应用程
序(CA和RA除外)。
证书持有者应包括以下功能:
a) 生成签名;
b) 生成证书注册请求;
c) 生成证书撤销请求;
d) 生成证书密钥更新请求。
证书持有者同时也是证书验证者,具备5.5中定义证书验证者的功能。
5.4.2 证书持有者的BYOD功能要求
证书持有者BYOD作为证书介质申请或使用证书服务时,该设备应安装有符合GB/T 37092的密
码模块并具备未被破坏的可信启动。该设备也应具备数字证书展示和通信能力,如:使用二维码交换证
书和签名。BYOD设备不应要求物理接入他人的设备进行证书展示和验证。
5.5 证书验证者
5.5.1 与互操作性有关的功能要求
证书验证者是使用证书的实体,包括CA、RA、个人、企业、用户和计算机系统。
证书验证者应包括以下功能:
a) 验证证书;
b) 从查询服务器中检索证书和CRL;
c) 验证证书认证路径。
具有证书持有者身份的证书验证者也能产生签名、支持撤销或更新证书。
5.5.2 验证证书的最小步骤要求
证书验证者应能获得从信任起点开始的完整的证书路径。信任起点可为:
a) 预埋的根证书;
b) 预埋的CA证书;
c) 经过验证后缓存的可信CA的证书。
证书验证者应从信任起点的证书开始,针对每个证书,逐一完成以下验证。
a) 验证证书基本信息:
1) 使用签发该证书的公钥验证签名;
2) 验证证书有效期;
3) 验证证书是否被撤销;
4) 验证证书签发者的名称。
b) 验证关键证书扩展。
c) 如果证书是自签发证书,且不是路径中的最终证书,跳过本步骤。否则,验证主体名称是否在
签发该证书的CA 证书中的nameContraints扩展(如适用)中一个允许的子树中,并验证
subjectAltName扩展中的每个替代名称(关键或非关键)是否在该名称类型的一个允许的子
树中。
d) 如果证书是自签发证书,且不是验证路径中的最终证书,跳过本步骤。否则,验证主体名称不
在签发该证书的CA证书中的nameContraints扩展(如适用)中的任何排除子树中,并验证
subjectAltName扩展中的每个替代名称(关键或非关键)不在该名称类型的任何排除子树中。
上述验证过程,任意项未通过都表示该证书不能被信任。
5.6 密码算法
PKI组件使用四类算法:密码杂凑算法、数字签名算法、消息鉴别码算法和对称加密算法。
PKI组件使用密码算法的总体安全要求如下:
a) 一个组件应实现至少一个数字签名算法,其他组件应能生成和验证由该算法生成的签名;
b) 组件应至少支持一个加密算法。
对于上述四类算法要求如下:
a) 应支持GB/T 32905规定的SM3密码杂凑算法;
b) 应支持GB/T 32918.2规定的SM2数字签名算法;
c) 应支持GB/T 15852.2规定的 MAC算法2(HMAC);
d) 应支持GB/T 32907规定的SM4分组密码算法。
6 互操作事务数据格式要求
6.1 总体要求
PKI互操作事务包括注册请求、更新证书、撤销证书、访问目录服务。CA系统、RA系统和证书持
有者应能实现这些事务。PKI事务的消息格式应符合GB/T 19714-2025第6章的要求。证书的数据
结构、证书扩展、证书撤销列表应符合GB/T 20518-2018的要求。PKI互操作事务中涉及证书应用综
合服务接口的应符合GB/T 43694的要求。
对于CA系统和RA系统物理上在一起且不支持远端RA系统的PKI产品,可忽略CA系统和RA
系统之间的消息交互。
6.2 注册请求
6.2.1 RA系统发起的注册请求
6.2.1.1 请求流程
RA系统请求CA系统为一个终端实体签发签名证书流程如下:
a) 终端实体通过物理方式(如提交实体U盘),在签名消息中向RA系统提供其公钥;
b) RA系统产生认证请求,利用签名消息保护请求,向CA系统为终端实体申请证书;
c) CA系统产生响应并发送给RA系统,响应消息中包含证书或错误代码的签名;
d) RA系统通过物理形式向终端实体提供CA的公钥和所签发的证书,终端实体也可直接从CA
获得证书。
6.2.1.2 从RA系统到CA系统的证书请求
RA系统建立证书请求的PKIMessage,并发送给CA系统,其PKIBody的请求代码为cr。其中,
PKIHeader的sender是RA的可辨别名,recipient是CA的可辨别名。PKIBody是CertReqMessages,
是一个CertReqMessage字段的序列,应包括如下信息:
● certReq含有请求者希望包含在证书中的信息;
● pop证明了对新证书私钥的拥有。
只支持终端实体产生签名密钥对,不支持终端实体产生加密密钥对。在进行签名私钥的拥有性证
明时,如果由RA系统来实现,当RA系统修改主体名时,popoSKInput域出现,并且包含原来的主体
名。否则,RA系统不修改主体名,pop域与请求者提交的主体名一致。
与证书内容相关的信息放入CertReqMessage的certReq中。
PKIProtection字段含有根据消息头和消息体的DER编码序列计算的RA系统的签名。
6.2.1.3 从CA系统到RA系统的证书响应
CA系统返回证书响应请求的PKIMessage给 RA 系统,其PKIBody的响应代码为cp。其中
PKIHeader的sender是CA 的可辨别名,recipient是 RA 的可辨别名。如果在证书请求中提供了
senderNonce,响应的PKIHeader应将其作为recipNonce。PKIBody是CertRepMessage,CertRepMessage
含有唯一的response字段,是包含certReqld、status和certifiedKeyPair的序列。如果CA系统签发了
一张证书,PKIBody应含如下信息:
● certReqId与请求中的certReqId匹配;
● status是granted或者是grantedWithMods;
● certifiedKeyPair序列至少含有一个字段certificate。
证书应满足如下要求:
● version号应是v3(2);
● publicKey字段应与证书请求中相同或者是由CA所产生的公钥;
● 主体可辨别名应与证书请求中相同;
● 签发者名字应是CA的可辨别名;
● 如果notBefore出现在证书请求中,证书应从签发日和notBefore所指之日的较晚者之后生效;
● 如果notAfter出现在证书请求中,证书应在该日或之前期满。
证书应包括如下扩展(extensions):
● 在certificatePolicies字段中至少包括一个证书策略的OID;
如果status是granted和grantedWithMods,failInfo字段可不存在。
如果CA拒绝了请求,PKIBody应含有如下信息:
● status是rejected;
● failInfo包含适当的错误代码。
如果status是rejected,certifiedKeyPair字段不必出现。
PKIProtection字段含有根据消息头和消息体的DER编码序列计算......
|