主页 购物车 询价 关于我们
www.GB-GBT.com
收录标准: 222533 (2026-05-22) 搜索

GM/T 0014-2023 相关标准英文版PDF

标准号码价格美元第2步(购买)交付天数标准名称
GM/T 0014-2023 1075 GM/T 0014-2023 3秒自动 数字证书认证系统密码协议规范
GM/T 0014-2012 570 GM/T 0014-2012 3秒自动 数字证书认证系统密码协议规范
   
基本信息
标准编号 GM/T 0014-2023 (GM/T0014-2023)
中文名称 数字证书认证系统密码协议规范
英文名称 Digital certificate authentication system cryptography protocol specification
行业 Chinese Industry Standard (推荐)
中标分类 L80
字数估计 53,517
发布日期 2023-12-04
实施日期 2024-06-01
发布机构 国家密码管理局

GM/T 0014-2023: 数字证书认证系统密码协议规范 ICS 35.030 CCSL80 中华人民共和国密码行业标准 代替GM/T 0014-2012 数字证书认证系统密码协议规范 2023-12-04发布 2024-06-01实施 国家密码管理局 发 布 目次 前言 Ⅲ 引言 Ⅳ 1 范围 1 2 规范性引用文件 1 3 术语和定义 1 4 缩略语 1 5 相关协议 1 5.1 通则 1 5.2 业务流程 2 5.3 CA与KMC系统间相关协议 5 5.4 CA与LDAP服务间相关协议 11 5.5 用户与LDAP服务间相关协议 13 5.6 CA与OCSP服务间相关发布协议 19 5.7 用户与OCSP服务间相关协议 19 6 协议报文语法 20 6.1 加密数据报文 20 6.2 杂凑数据报文 20 6.3 数字签名报文 20 6.4 数字信封报文 20 附录A(规范性) 系统与格式定义 21 附录B(规范性) 非实时发布证书流程 25 附录C(资料性) RA与CA间相关协议 26 附录D(资料性) 协议报文实例 35 参考文献 47 前言 本文件按照GB/T 1.1-2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定 起草。 本文件代替 GM/T 0014-2012《数字证书认证系统密码协议规范》。与 GM/T 0014-2012相 比,除结构调整和编辑性改动外,主要技术变化如下: a) 删除了术语“CA撤销列表”“证书认证路径”“证书策略”“证书撤销列表发布点”(见2012年版 的3.1、3.3、3.4、3.5); b) 增加了缩略语RA、CA和LDAP(见第4章); c) 更改了缩略语KM为KMC(见第4章,2012年版的第4章); d) 删除了缩略语OID、PKCS#1、PKCS#7、SOCSP和TBS(见2012年版的第4章); e) 更改了“5.1概述及协议流程”为“5.1通则”和“5.2流程”,并相应递增后续编号(见第5章, 2012年版的5.1); f) 删除了对LDAP的RFC引用(见2012年版的5.4.1); g) 删除了SOCSP证书状态查询协议(见2012年版的5.5.2、5.6.2); h) 删除了SHA_1算法(见2012年版的6.2); i) 更改了名词“IE浏览器”为“浏览器”(见C.1,2012年版的B.1)、“ActiveX”为“组件”(见 C.2,2012年版的B.2)。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。 本文件由密码行业标准化技术委员会提出并归口。 本文件起草单位:北京国脉信安科技有限公司、上海信息安全工程技术研究中心、国家信息安全工 程技术研究中心、格尔软件股份有限公司、北京海泰方圆科技股份有限公司、北京数字认证股份有限公 司、北京信安世纪科技股份有限公司。 本文件主要起草人:袁文恭、刘平、郭晓雷、袁峰、李增欣、杨恒亮、谢安明、谭武征、郑强、柳增寿、 李元正、汪宗斌、封维端。 本文件及其所代替文件的历次版本发布情况为: ---2012年首次发布为GM/T 0014-2012; ---本次为第一次修订。 引 言 数字证书认证系统是我国信息安全基础设施建设中的重要内容。本文件是为我国信息安全基础设 施建设中关于数字证书认证系统密码协议提供的规范。本文件中的安全协议以密码技术为基础,为数 字证书认证系统中各组成部分之间的密码服务,提供统一、通用的通联协议,以满足实体对数字证书认 证系统的真实性、保密性、完整性和不可否认性的安全需求,支持数字证书认证系统中不同部分之间的 互联互通。 数字证书认证系统密码协议规范 1 范围 本文件规定了数字证书认证系统中的涉及密码技术的安全协议和协议报文。 本文件适用于数字证书认证系统的设计、建设、检测、运行及管理。对于组织或机构内部使用的数 字证书认证系统密码协议的建设、运行及管理,可参考使用。 2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文 件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于 本文件。 GB/T 19713 信息技术 安全技术 公钥基础设施 在线证书状态协议 GB/T 20518 信息安全技术 公钥基础设施 数字证书格式 GB/T 25056 信息安全技术 证书认证系统密码及其相关安全技术规范 GM/T 0006 密码应用标识规范 GM/T 0009 SM2密码算法使用规范 GM/T 0010 SM2密码算法加密签名消息语法规范 GM/Z4001 密码术语 3 术语和定义 GM/Z4001界定的术语和定义适用于本文件。 4 缩略语 下列缩略语适用于本文件。 5 相关协议 5.1 通则 本章给出了数字证书认证系统中各部分的相关流程和密码协议,包括RA与客户端间、RA和CA 和KMC间、CA与 KMC间、CA与LDAP间、CA与 OCSP服务间、用户与 OCSP服务间的业务流 程,以及CA同KMC之间安全协议、CA同LDAP服务之间安全协议、CA同 OCSP服务之间安全协 议、用户同OCSP服务之间安全协议。对于国家根数字证书认证系统因仅有RA、CA部分,可参见RA 与CA业务流程。 本文件给出了与协议直接相关的格式和语法。其中系统与格式定义应符合附录A中的规定;其中 凡涉及RSA密码算法的,其密钥结构应符合PKCS#1的规定,其封装结构应符合PKCS#7的规定; 凡涉及SM2算法的,其密钥结构应符合GM/T 0009的规定,其封装结构应符合GM/T 0010的规定; 凡涉及对象标识符的应符合GM/T 0006的要求。 5.2 业务流程 5.2.1 总业务流程 本文件定义的客户端、RA、CA、KMC以及LDAP和OCSP间的总业务流程见图1。 图1 总业务流程图 非实时发放证书的流程应符合附录B的规定。 5.2.2 RA与客户端间业务流程 RA同客户端间的流程见图2。 图2 RA与客户端业务流程 5.2.3 RA、CA与KMC间业务流程 RA、CA与KMC间的业务流程见图3。 图3 RA、CA与KMC业务流程 RA同CA间的相关协议见附录C。 5.2.4 CA与KMC间业务流程 CA与KMC间的流程见图4。 图4 CA与KMC业务流程 5.2.5 CA与LDAP间业务流程 CA同LDAP服务间的流程见图5。 图5 CA与LDAP服务业务流程 5.2.6 CA与OCSP服务间业务流程 CA与OCSP服务间流程应符合GB/T 19713的规定。 5.2.7 用户与OCSP服务间业务流程 用户与OCSP服务间流程应符合GB/T 19713的规定。 5.3 CA与KMC系统间相关协议 5.3.1 概述 KMC系统接收CA系统的密钥服务请求,将处理结果返回给CA。本文件中的密钥服务协议包括 申请密钥对、恢复密钥对和撤销密钥对。每个服务都按照请求-响应的步骤执行。 请求:请求由CA发起,发送到KMC。CA在生成用户加密证书、更新加密证书或者撤销加密证书 时,首先组织密钥服务请求,发送到KMC,并延缓自身的事务处理过程,等待KMC响应返回。 响应:响应由KMC发起,发送到CA。KMC在接收到来自CA的请求后,检查确定请求合法性,处 理服务请求,并将结果返回给CA。 整个服务过程见图6。 图6 CA和KMC通信过程 5.3.2 协议内容 协议内容包括以下内容。 a) 请求,也称密钥服务请求,包含CA请求的类型、性质以及特性数据,该请求被发送到KMC并 得到服务响应。服务请求应包括如下数据: ● 协议版本(当前版本为2); ● 服务请求标识符; ● CA标识符; ● 扩展的请求信息; ● 请求信息的签名。 b) 响应,是KMC对来自CA请求的处理响应。KMC的响应包括如下数据: ● 协议版本(当前版本为2); ● 响应标识符; ● KMC标识符; ● 响应信息; ● 响应信息的签名。 c) 异常情况,当CA系统和KMC系统任何一方处理发生错误时,应向对方发送错误信息。错误 可为: ● 验证请求失败:KMC验证来自CA证书或CA请求数据失败,CA收到后应重新进行申请; ● 内部处理失败:KMC处理CA请求过程中发生内部错误,通知CA该请求处理失败,需要 重新申请。 本文件采用抽象语法记法(ASN.1)来描述具体协议内容。如果无特殊说明,默认为显式标记。 5.3.3 密钥申请协议 5.3.3.1 请求数据格式 CA请求的基本格式如下: CARequest∷=SEQUENCE{ ksRequest KSRequest, 其中: KSRequest∷=SEQUENCE{ version VersionDEFAULTv2, taskNo INTEGER Version∷=INTEGER{v2(1)} EntName∷=SEQUENCE{ entName GeneralName, Request∷=CHOICE{ applyKeyReq [0]IMPLICTApplyKeyReq, KSRequest结构的各项含义如下。 a) 版本 version版本描述了请求语法的版本号,当前版本为2,值为1。 b) 请求者标识符 caName请求者标识符,是申请者的唯一名称,该值由实际运行CA和KMC约定。 EntName结构中,entPubKeyHash是申请者公钥的杂凑值。该值将通过对发布者证书中的主体 公钥字段(不含标记和长度)进行计算。hashAlgorithm字段表示计算该杂凑值所使用的杂凑算法。se- rialNumber是申请者的证书序列号。 c) 请求类型 Request请求包类型,值为applyKey时表明该包为申请密钥申请包,值为restoreKey时表明该包 为恢复密钥申请包,值为revokeKey时表明该包为撤销密钥申请包。 Request的三种数据格式为: ● ApplyKeyReq包 appKeyType AlgType, appKeyLen AppKeyLen, retAsymAlg AlgType, retSymAlg AlgType, retHashAlg AlgType, appUserInfo AppUserInfo AlgType∷= AlgorithmIdentifier notBefore GeneralizedTime, extendInfo [2]PKIFreeTextOPTIONAL 密钥对的类型,retAsymAlg、retSymAlg、retHashAlg分别为KMC响应数据包中非对称算法、对称算 法、杂凑算法类型。 AppKeyLen表示申请的密钥长度。 示例1:十进制256表示申请256比特的密钥。 AppUserInfo表示申请包中对应用户信息,依次为终端用户加密证书序列号、终端用户保护公钥、 密钥有效起始时间、密钥截止时间、用户姓名、地区代码以及扩展信息。 对于同一个CA,其申请时提交的用户加密证书序列号应是唯一的,如果需要使用原有证书序列号 再次申请密钥对,则应先请求将原申请密钥对撤销。 userPubKey为终端用户保护公钥,该公钥应由终端用户证书载体生成,用来在密钥传递中保护用 户加密私钥。该公钥宜采用终端用户签名公钥。 用户信息结构中,userName为可选项,该项用来标识用户名称,当CA将该项提交给 KMC时, KMC应将其保存到库中。 dsCode为可选项,CA可使用该项标识密钥的地区属性,当dsCode存在时,KMC应将其保存到 库中。 extendInfo扩展信息为可选项,用来表示CA需要往KMC发送关于该用户的个性信息,该域最大 应能处理100字节数据。 示例2:若KMC按照区域管理密钥,则CA可利用该域填写该用户的区域信息,KMC读出该域值后保存到库中。 ● RestoreKeyReq包 retAsymAlg AlgType, retSymAlg AlgType, retHashAlg AlgType, userPubKey SubjectPublicKeyInfo userCertNo为用户加密证书序列号。 userPubKey为终端用户保护公钥。 ● RevokeKeyReq包 UserCertNo为用户证书序列号。 d) 请求时间 requestTime为请求生成时间,该时间为CA产生请求的时间。 e) 任务序列号 taskNo为请求任务序列号,该任务序列号是申请者用来区分多次申请时候的一个标识符,以确保 KMC和CA能正确关联请求-响应过程。 KMC应能处理不大于二十字节的任务序列号,而CA应确保不使用大于二十字节的任务序列号。 5.3.4 响应 5.3.4.1 响应数据格式 KMC响应的格式如下: KMRespond∷=SEQUENCE{ ksRespond KSRespond, 其中: KSRespond∷=SEQUENCE{ version VersionDEFAULTv2, taskNo INTEGER Respond∷=CHOICE{ 5.3.4.2 KSRespond及其结构解释 KSRespond结构的各项含义如下。 a) 版本 version为响应的版本号,当前版本为2,值为1。 b) 响应者标识符 KMName为响应者标识符,其成员分别为响应者的名称、响应者公钥的杂凑值、杂凑算法以及响应 者的证书序列号。 c) 响应类型 Respond为响应类型,当值为applyRespond时该包为申请密钥响应包,值为restoreRespond时该 包为恢复密钥响应包,值为revokeRespond时该包为撤销密钥响应包。 d) Respond响应子包 Respond响应子包共有如下三种数据格式。 ● retKeyRespond包 格式如下: retKeyRespond∷=SEQUENCE{ retPriKey SM2EnvelopedKey retPriKey是返回给申请者的用户加密私钥数据信封,即对私钥作带签名的加密信封。 ● RevokeKeyRespond包 UserCertNo指定用户加密证书序列号,该项值取自申请包。 ● ErrorPkgRespond包 如下: ErrorPkgRespond∷=SEQUENCE{ errNo INTEGER, errDesc [0]PKIFreeTextOPTIONAL 响应生成时间,该时间即为KMC产生响应的时间。 f) taskNo任务序列号 响应的任务序列号,该任务序列号值取自申请者数据包。 5.4 CA与LDAP服务间相关协议 5.4.1 通则 证书与证书撤销链发布是指CA把新签发的证书与证书撤销链送到LDAP目录服务器,以供用户 查询、下载。 CA到LDAP服务间的数据传输应符合GB/T 25056的规定。 5.4.2 发布协议 消息包结构定义为: PkixIssue∷=SEQUENCE{ CASignature Signature version Version,--版本号,值为1 type INTEGER, --0:向LDAP或OCSP更新根证书, --1:向LDAP发送证书, --2:向LDAP发送作废证书序列号, --3:向LDAP发送作废证书链, --4:向OCSP发送证书状态, --8:向LDAP发送交叉认证证书,LDAP自己用根证书与此包中的 第一个证书组成PKCS#7证书发布链 transNonce OCTETSTRINGOPTIONAL,--包内随机数 number INTEGEROPTIONAL,--包内证书或证书状态或证书撤销链数目 time GeneralizedTime, --接收方比较此时间,根据约定时间延迟确定是否接收包内容 --如果是证书,放在本项中,如果是更新根证书将发布4个证书,依 次为OldWithNew、NewWithOld、NewWithNew签名证书、New- WithNew加密证书 certstatue [1]SEQUENCEOFSEQUENCE { certId CertID, BeforeTime GeneralizedTime, --0有效,1无效,无效时应有原因项 statueTime GeneralizedTime, }mCRL [2]SEQUENCEOFSEQUENCE { --区域区别号,CRL发布点可有多个,发布内容可不 同,只有唯一地点的为0 CLRSegment INTEGER, --证书链的块号,为防证书链太大,可按证书号分 块,同块内证书在同一条链中 CRLNumber INTEGER,--证书链基本序列号 DeltareCRLNumber INTEGEROPTIONAL,--证书链增量序列号 CertificateList SEQUENCE {--作废证书链 tbsCertList TBSCertList, signatureValue BITSTRINGOPTIONAL, --CA的签名,若是根证书更新包这里的签名是新根的签名,接收 方应逐级验证,以确保新根合法 收到消息的回应包为: PkixIssueResponse∷=SEQUENCE{ version Version,--版本号,值为1 type INTEGER, --0:向LDAP或OCSP更新根证书, --1:向LDAP发送证书, --2:向LDAP发送作废证书序列号, --3:向LDAP发送作废证书链, --4:向OCSP发送证书状态, --8:向LDAP发送交叉认证证书,LDAP自己用根证书与此包 中的第一个证书组成PKCS#7证书发布链 transNonce OCTETSTRINGOPTIONAL,--包内随机数 number INTEGEROPTIONAL,--包内证书或证书状态或证书撤销链数目 time GeneralizedTime,--接收方时间 ResponseStatue INTEGER--0为正常接收,1为未接收,请下次重发 如果CA收到回应后验证签名失败或传输随机数不同,则此次发布失败,应重新打包再发布。 5.5 用户与LDAP服务间相关协议 5.5.1 通则 LDAP目录可用来存储多种信息,作为PKI的核心组件其作用主要用来存放证书与证书撤销列 表,供用户查询。 LDAP消息协议数据单元LDAPMessage为: LDAPMessage∷=SEQUENCE{ messageID MessageID, protocolOp CHOICE{ bindRequest BindRequest, searchResEntry SearchResultEntry, addRequest AddRequest, modDNRequest ModifyDNRequest, abandonRequest AbandonRequest, }, MessageID∷=INTEGER(0.maxInt) 除了在上面定义的LDAPMessage,在定义协议操作时,也可使用下面的定义: LDAPString∷= OCTETSTRING 际上该串能使用的合法字符集应由IA5字符集限定。 LDAPDN∷=LDAPString LDAPDN和RelativeLDAPDN分别表示一个标识名和一个相对标识名: attributeType AttributeType, 注意这里的AttributeType,如果服务器端拥有某个属性的文本名,则在查询结果中返回文本名,文 本名字(“OrganizationName”)优先于点数方式(“2.5.4.10”)。服务器端应拥有一个较全的属性名列 表,且便于客户端知道。 一个类型为AttributeValue的域的值用目录中的AttributeValue类型的一个八位编码串来表示。 LDAPResult∷=SEQUENCE{ resultCode ENUMERATED{ compareFalse(5), --9reserved-- referral(10),--new --22-31unused-- noSuchObject(32), --37-47unused-- busy(51), --55-63unused-- namingViolation(64), --70reservedforCLDAP-- --72-79unused-- other(80) },--81-90reservedforAPIs referral [3]ReferralOPTIONAL 返回包含LDAPResult结构中的不同域的回应给客户,来指明协议操作请求的最终状态。对于服务 器,这个结构中的errorMessage域应用来返回一个包含可读文本的错误诊断的ASCII串给客户。由于 这个错误诊断不是标准的,在实现中不应依赖这些返回值。如果服务器不返回一个文本的错误诊 断,LDAPResult结构中的errorMessage应包含一个长度为零的字符串。 应的matchedDN域应设为在DIT中最为匹配的条目,而且应是所提供名字的简短格式。或者,如果别 名已被丢弃,应返回结果名字。在其他情况下,matchedDN域都应设为NULLDN(也就是长度为零的 字符串)。 客户和服务器之间的协议会晤包括绑定、解除绑定、查询、插入、修改、删除和丢弃。用户只能访问 从LDAP,LDAP应拒绝用户的插入、修改、删除功能。协议会晤中通用部分如下: 绑定操作的功能是在客户和服务器之间初始化一个协议会晤,并允许服务器对客户进行认证。绑 定请求定义如下: BindRequest∷= [APPLICATION0]SEQUENCE{ version INTEGER(1.127), name LDAPDN, simple [0]OCTETSTRING,--1and2reserved sasl [3]SaslCredentials 绑定请求的参数为以下内容。 ---版本,版本号指定本协议会晤中所使用协议的版本。本文件为LDAP版本3。由于没有版本 选择协商,客户应把这个参数设为它所希望的值。如果客户端设定的版本为LDAP版本2,服 务器端则应不返回版本3所加内容。如果客户端没有绑定请求(V3版可没有绑定),服务器端 应认定客户端支持V3版协议。 ---名称,客户希望绑定的目录对象的名称。可为空值(一个长度为零的字符串),表示匿名绑定。 SecurityLayer)是一个附加在面向连接协议上的框架,它提供了更高一级的安全认证机制。 但作为从LDAP,客户查询的认证必要性不大。 绑定操作的绑定回应为: BindResponse∷= [APPLICATION1]SEQUENCE{ 放弃绑定操作是临时终止一个协议会晤,放弃绑定操作定义如下: UnbindRequest∷= [APPLICATION2]NULL 若没有定义放弃绑定操作回应。在收到一个放弃绑定请求后,服务器可假设发送请求的客户已终 止该会晤,所有已收到的还未处理的请求可被丢弃。 丢弃操作是允许客户请求服务器终止一个已发出的操作请求。丢弃操作定义如下: AbandonRequest∷= [APPLICATION16]MessageID 在丢弃操作中没有定义相应的回应。在发送一个丢弃操作后,一个客户可能期望丢弃请求中包含 的消息ID标识的操作已被丢弃。如果服务器在把一个查找操作的回应发送给客户时,收到对该查找操 作的丢弃请求,服务器应停止发送回应,并立即终止该查找操作。 5.5.2 证书查询与下载协议 查找操作允许客户请求代表他的服务器进行一次查找。查找请求定义如下: SearchRequest∷= [APPLICATION3]SEQUENCE{ baseObject LDAPDN, scope ENUMERATED{ wholeSubtree (2) }, derefAliases ENUMERATED{ derefAlways (3) }, sizeLimit INTEGER(0.maxInt), filter Filter, Filter∷=CHOICE{ and [0]SETOFFilter, or [1]SETOFFilter, not [2]Filter, substrings [4]SubstringFilter, SubstringFilter∷=SEQUENCE{ substrings SEQUENCEOFCHOICE{ any [1]LDAPString, final [2]LDAPString matchValue [3]AssertionValue, 查找请求的参数为以下内容。 ---baseObject:一个相对于要进行查找操作的基本对象条目。 ---scope:指示要查找的范围。该域可能的语义上的值与目录查找操作中的范围域的语义值是一 致的。 ---derefAliases:指示在操作中别名对象该如何处理。该域可能的语义上的值按照升序的顺序 进行。 ---neverDerefAliases:在查找或定位查找的基本对象时不丢弃别名引用。 ---derefInSearching:在查找过程中,丢弃基本对象的下一级的别名引用,但对基本对象进行定位 时,不丢弃别名引用。 时,不丢弃别名引用。 ---derefAlways:在定位基本对象和查找基本对象的下一级时都丢弃别名引用。 ---sizelimit:一个sizelimit限制了可返回的最大查找结果的条目数量。如果该域的值为0,表示 不限制查找的sizelimit。 ---timelimit:一个timelimit限制了一个查找最多允许的时间(以秒计算)。如果该域的值为 0,表示不限制查找的timelimit。 ---attrsOnly:指示在返回的查找结果中是否要包含属性类型和属性值,或者仅包含属性类型。 如果该域设为TRUE,仅返回属性类型(没有值),如果该域设为FALSE,同时返回属性类型 和属性值。 ---filter:一个过滤器定义了一个应满足的条件,以使该查找能匹配给定的条目。 ---attributes:要返回的查找结果中的每一个条目的属性列表。一个空的列表表示查找结果应包 含每一个条目的所有属性。 在收到一个查找请求后,服务器返回结果为: SearchResultEntry∷= [APPLICATION4]SEQUENCE{ objectName LDAPDN, attributes PartialAttributeList SearchResultDone∷= [APPLICATION5]LDAPResult 在收到一个查找请求后,服务器对DIT进行查找。服务器把一系列的回应返回给客户。这些回应 包括以下内容。 a) 零个或多个查找回应,每个回应包含所查找到的一个条目。在每个回应的后面跟着回应的序 列号。 b) 一个包含操作成功或对所发生错误的详细描述的单个查找回应。 每个返回的条目应包括所有的属性,以及在查找请求的“attributes”域中指定的所要求的关联 的值。 DIT的“列表”操作可通过具有检查objectClass属性是否存在的一个LDAP过滤器查找来模拟。 同样,DIT的“读”操作可通过具有同样过滤器的LDAP查找来模拟。 协议报文实例见附录D。 5.5.3 CRL查询与下载协议 证书或证书撤销列表以一条条数据的形式存放在 LDAP 的不同的分支下。LDAP 根据 “baseObject”与属性值查询满足条件的记录返回用户查询下载的证书或CRL。 baseObject是查找的基本条件,具体查找一条CRL应根据目录树的设计区别对待。CRL目录有 两种设计。 a) 根据证书号分段,其中CRLNumber放到serialnumber中,分段号组合到ou中,具体的区别名 放到dc中。 示例1:如201段CRLLDAPDN存放“serialnumber=???,ou=crl201,dc=isc,dc=com”,202段CRLLDAPDN存 放“serialnumber=???,ou=crl202,dc=isc,dc=com”。 b) 增量CRLCRLLDAPDN存放,递增的号码放入serialnumber。 示例2:如“serialnumber=???,ou=dcrl,dc=isc,dc=com”。因为增量CRL的序列号是CRL基本序列号的累 加,如基本号为1,增量号为29,下一个基本号为10,接下来的增量号为1119,这个递增的号码不会重复。 对第一种情况,若要查找CRLNumber为100,分段号为10的CRL,baseObject可这样组织:“seri- alnumber=100,ou=crl10,dc=isc,dc=com”,发送这样的请求就可获得具体的CRL列表。 对第二种情况,若要查找serialnumber为100,baseObject可这样组织:“serialnumber=100,ou= dcrl,dc=isc,dc=com”,发送这样的请求就可获得具体的CRL列表。对于一个应用来说,如果这个列 表是基本表,时间也满足要求,通过这个表可知道证书是否作废;如果这个列表是增量表,时间也满足要 求,通过这个表还不能知道证书是否作废,这时还要下载对应此表的基本表以及到目前表为止的增量 表,经过每个表的检查方知具体证书的作废情况。 5.6 CA与OCSP服务间相关发布协议 CertID结构用于标识特定的证书。 CertID∷=SEQUENCE{ 证书状态的发布有两种方式,开发者可根据情况自选一种。一种是PKIXIssue方式,按照CA到 LDAP服务的发布协议中发布到OCSP服务的规定。另一种是PKIMessage方式,定义格式如下: 当CA已经或将要作废一个特定的证书时,可发布一个有关该事件(可能是将要发生的事件)的 告示。 RevAnnContent∷=SEQUENCE{ status PKIStatus, certId CertID, badSinceDate GeneralizedTime, --额外的CRL细节(如crlnumber、reason、 location) CA可使用这样的告示来警告(或通知)一个申请者其证书将要(或已经)作废。这一消息通常用于 作废请求并不是由相关证书的subject发起的情况。 wilBeRevokedAt字段包含新的条目将增加到相关CRLs的时间。 5.7 用户与OCSP服务间相关协议 OCSP使得应用程序可获得所需要检验证书的状态。 这个协议规定了在应用程序检查证书状态和OCSP服务器提供状态之间所需要交换的数据。 一个OCSP请求包含以下数据:协议版本、服务请求、目标证书标识、可能被 OCSP服务器处理的 可选扩展。作为OCSP服务器应检测客户请求与服务策略之间的合理化。如果请求格式不对或服务 器要求的客户信息不够,则OCSP服务器应产生一个错误信息;否则返回一个确定的回复。 具体协议应符合GB/T 19713的规定。 6 协议报文语法 6.1 加密数据报文 加密数据报文为不附带任何编码标示的原始密文数据。 使用SM2算法的加密数据报文定义应符合GM/T 0009的规定。 6.2 杂凑数据报文 Digestinfo∷=SEQUENCE{ digest Digest Digest∷= OCTETSTRING 其中: Digest是消息杂凑进程的结果。 6.3 数字签名报文 基于SM2算法的数字签名报文格式应符合GM/T 0010的规定,基于RSA算法的数字签名报文格 式应符合PKCS#7的规定。 6.4 数字信封报文 基于SM2算法的数字信封报文格式应符合GM/T 0010的规定,基于RSA算法的数字信封报文格 式应符合PKCS#7的规定。 附 录 A (规范性) 系统与格式定义 A.1 证书模板格式 本文件中所描述证书应符合GB/T 20518的规定。 不同的PKI管理消息要求消息的发起者指明证书中必备的一些域。证书模板结构允许一个终端 实体或者RA尽可能指定其要求的证书内容。除了域内容是随意填写之外,证书模板可等同于一个 证书。 即使消息的发起者指定全部它所需求的证书内容,而CA在签发证书时有权进行修改。如果这样 签发的证书不能被消息请求者接受,可拒绝确认消息或发送一个错误消息。 证书模板语法如下: CertTemplate∷=SEQUENCE{ version [0]Version OPTIONAL, signingAlg [2]AlgorithmIdentifier OPTIONAL, issuer......