信息技术安全技术公钥基础设施证书管理协议

信息技术安全技术公钥基础设施证书管理协议

国家标准 GB/T19714一2005 信息技术安全技术公钥基础设施 证书管理协议 Informationtechnology一Seeuritytechnology一lnternetpublickey infrstrueture一Certinieatemanagememtprotoeol 2005-04-19发布 2005-10-01实施 国家质量监督检验检疫总局 发布 国家标准化管理委员会国家标准
GB/T19714一2005 附录D资料性附录请求消息行为说明 42 43 附录E(资料性附录使用“口令短语” 45 附录F(规范性附录“可编译”的ASN.1模块 56 附录G(资料性附录用于E-MAIL或者HTTP的MIME类型 57 参考文献
GB/T19714一2005 前 言 本标准是依据IETFRFC2510制定的 本标准凡涉及密码算法相关内容,按国家有关法规实施 本标准中引用的RsA,SHAl,DH密码算法均为举例性说明,具体使用时均须采用国家商用密码 管理委员会批准的相应算法 本标准的附录B,附录C、附录F为规范性附录,附录A、附录D附录E,附录G为资料性附录 本标准由信息产业部提出 本标准由全国信息安全标准化技术委员会(TC260)归口 本标准主要起草单位;北京创原天地科技有限公司、电子技术标准化研究所 本标准主要起草人;林雪焰,吴志刚、王炳艳、陈震琦、张科研、李丹、罗锋盈、陈星
GB/T19714一2005 引 言 本标准描述了公钥基础设施(PKI)证书管理协议,定义了与证书产生和管理相关的各方面所需要 的协议消息,主要包括;申请证书、撤销证书、密钥更新、密钥恢复、交叉认证等等 公钥基础设施中总共有四类实体:CA、RA、终端实体、证书/CRL.库,如何保证四实体之间的通信 安全、在证书业务中如何对四类实体进行管理,这些问题是本标准解决的主要问题 N
GB/T19714一2005 信息技术安全技术公钥基础设施 证书管理协议 范围 本标准描述了公钥基础设施(PKI)中的证书管理协议,定义了与证书产生和管理相关的各方面所 需要的协议消息,这些消息主要包括申请证书、撤销证书、密钥更新、密钥恢复、交叉认证等 本标准主要适用于在安全或不安全环境中实能PKI组件并实施管理,可作为PRI运背惧构.PKI 组件开发者的参考指南 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款 凡是注日期的引用文件,其随后所有 的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而,鼓励根据本标准达成协议的各方研究 是否可使用这些文件的最新版本 凡是不注日期的引用文件,其最新版本适用于本标准 GB/T16264.8一2005信息技术开放系统互连目录第8部分;公钥和属性证书框架(ISO/ IEC9594-8;2001,IDT) RFC2511因特网X.509公开密钥基础设施证书消息格式 术语和定义 下列术语和定义适用于本标准 抽象语法记法一(ASN.1)AbstraetSyntaxNotatio1ASN.1) 用来组织复杂数据对象的表示法 3 公钥证书publickeycertificate 用户的公钥连同其他信息,并由发布该证书的证书认证机构的私钥进行加密使其不可伪造 3.3 证书持有者certifieateholder 有效证书的主体对应的实体 3. 证书用户certifieateuser 需要确切地知道另一实体的公开密钥的某一实体 3.5 证书认证机构(CACertifieateAuthority(CA) 负责创建和分配证书,受用户信任的权威机构 用户可以选择该机构为其创建密钥 3.6 证书认证路径certificationpath 个DIT中对象证书的有序序列,通过处理该有序序列及其起始对象的公钥可以获得该路径的末 端对象的公钥
GB/T19714一2005 认证业务说明(cPs》certine ieationPraetieeStatement(CPs 证书认证机构发放证书时遵循的业务说明 3.8 交叉证书eross-certifieate 两个CA间为交叉认证所互相签发的数字证书 g 3. CRL分布点CRLdistributiopoint 一个CRL目录项或其他CRL分发源;由CRL分布点分发的CRL可以包括仅对某CA所发证书 全集某个子集的撤销条目,或者可以包括有多个CA的撤销条目 3.10 证书撤销列表(CRL)CertifieateRevoeationList(CRL 个已标识的列表,它指定了一套证书发布者认为无效的证书 除了普通CRL.外,还定义了一些 特殊的CRL类型用于覆盖特殊领域的CRL 3.11 发证certify 颁发一个证书的行为 3.12 可辨别编码规则(DER)DistinguishedEncdingRules(DER) 对ASN.1对象进行编码的规则 注本标准中使用DER对AsN.1对象进行编码 3.13 数字签名digitalsigmature 允许接收者验证签名人的身份和数据完整性的数据单元 14 3. 目录服务(Ds)Directoryserice(Ds) 分布在网络中的各种节点或服务器提供的分布式数据库服务 15 3. 终端实体endentity 不以签署证书为目的而使用其私钥的证书主体或者是依赖(证书)方 3.16 散列函数hashfunetion 哈希函数 将值从一个大的(可能很大)定义域映射到一个较小值域的(数学)函数 “好的”散列函数是把该函 数应用到大的定义域中的若干值的(大)集合的结果可以均匀地和随机地)被分布在该范围上 3.17 散列码lHashcode 散列函数的输出比特串 3.18 消息认证码(MAC)MessageAuthentieationCode(MIAC 通过密码技术由消息产生的认证数据
GB/T19714一2005 3.19 消息摘要messagedigest 散列一个消息后得到的固定长度数据 3.20 个人安全环境(PSE)PersomalSseeurityEnviromment(PSE 证书及私钥的终端实体的安全本地存储 PoP 拥有证明(PoP)ProofofPossession 终端实体用以证明自己拥有即能够使用)与为之申请证书的公钥相对应的私钥 3.22 策略映射polieymapping 当某个域中的一个CA认证另一个域中的一个CA时,在第二个域中的特定证书策略可能被第 个域中的证书认证机构认为等价但不必在各方面均相同)于第一个域中认可的特定证书策略 3.23 注册机构(RA RegistrationAuthority(RA 为用户办理证书申请,身份审核、证书下载、证书更新、证书注销以及密钥恢复等实际业务的办事机 构或业务受理点 3.24 资料库repository 存储证书和CRL等信息,并提供无需验证的信息检索服务的数据库 自颁发证书self-issuelcertifieate 证书的主体和颁发者相同的CA证书 缩略语 下列缩略语适用于本标准: CA证书认证机构 CRL证书撤销列表 PKcs公钥密码系统 HKI公钳基础设施 O拥有证明 PsE个人安全环境 RA注册机椅 TCP传输控制协议 PKI管理概述 5.1PK1管理模型 在详细阐述特定的消息格式和流程之前,首先要定义一下PKI管理中所涉及到的实体以及它们之 间的交互行为(根据PKI管理所需的功能) 然后再对这些功能进行归类,以包含可以确定的不同类型 的终端实体 5 PKI实体的定义 2 PKI管理中所涉及到的实体包括终端实体和证书认证机构 注册机构也可以被包括在内
GB/T19714一2005 5.2.1主体和终端实体 终端实体是不以签署证书为目的而使用其私钥的证书主体或者是依赖(证书)方 “主体”在此处是指被授予证书的实体,一般在证书的主体或主体可替换名字段中指定 当要区分 主体所使用的工具和/或软件时例如;一个本地的证书管理模块),使用术语“主体设施” 通常优先使 用术语“终端实体”而不是“主体",以防止与证书字段名中的主体相混淆 需要着重指出的是;终端实体在此处不仅包括应用软件的使用者,也包括软件本身例如IPSec的 情况) 这一因素影响着PKI管理操作所使用的协议 例如,与个人用户相比,应用软件更有可能确切 知道需要使用证书中的哪个扩展项 PKI管理实体也被看作为一个终端实体,因为它们有时候也在证 书(或交叉证书)的主体或主体可替换名字段中被指定 如无特殊说明,术语“终端实体”将不会被用来 指代PKI管理实体 所有的终端实体都需要安全可靠的访问一些本地信息,至少包括:实体自己的名字和私钥,被该实 体直接信任的CA的名字及其公钥(或公钥指纹,如果可以通过其他的方式得到自签名证书) 软件实 现可以使用安全本地存储机制存储上述信息,但不限于上述信息例如:还可以包括用户自己的证书以 及应用软件特有的信息) 存储方式也可以不同,例如普通的文件或抗攻击的密文存储介质 像这样安 全的本地存储在这里被称之为终端实体的个人安全环境 尽管有关PSE格式的内容已经超出本标准的范围(与设备及其他信息相关),但这里定义了一种通 用的PSE数据交换格式 认证响应消息 5.2.2证书认证机构(CA 证书认证机构是负责创建和分配证书,受用户信任的权威机构 用户可以选择该机构为其创建 密钥 从终端实体的角度出发,cCA可以是,也可以不是一个事实上真正的“第三方” 绝大多数情况下， CA与其所服务的终端实体属于同一个机构 同样,我们使用术语“CA"指代证书中签发者(issuer)字段所代表的实体 当需要与CA所使用的 软硬件工具相区分时,我们使用术语“CcA设施” CA设施一般包括离线模块和在线模块,只有CA的离线模块可以使用CA的私钥 尽管是否这样 做与CA的策略相关,但这取决于软件实现者 我们使用术语“根cA”来指代被终端实体直接信任的CA;即安全地获取根CA的公钥需要一些额 外的步骤 这一术语并不意味着根CA必须处于CA体系层次的顶层,它只是说明该CA是被终端实 体直接信任的 “下级CA”(子CA)不是终端实体的根CA 通常,下级CA不是任何实体的根CA,但这并不是强 制的 5.2. 注册机构(RA) 3 注册机构是为用户办理证书申请、身份审核、证书下载、证书更新、证书注销以及密钥恢复等实际业 务的办事机构业务受理点,亦称证书注册审核中心 除了终端实体和CA之外,很多应用环境要求把注册机构从证书认证机构中独立出来 RA存在 的原因参见附录A.)RA所具有的功能将因情况不同而有所不同.可能包括个人身份鉴别介质分发、 作废报告、名称分配、密钥产生、密钥归档等等 本标准将RA作为可选的组成部分,当RA不存在时,假定CA可以实现RA的功能 从终端实体 的观点看,它们都使用相同的PKI管理协议 同样,当需要区分RA和RA所使用的工具时,使用“RA设施"这个术语 应该注意到RA本身也是一个终端实体,一个被验证了的终端实体,它有自已的私钥进行数字签名 和身份认证 CA设施如何把某些终端实体认定为RA则是一个实现问题(本标准不阐述特定的RA认 证操作) 并不强制RA必须可以被与其正通信的CA所认证(所以一个RA可以只被认证一次,与多
GB/T19714一2005 个CA协同工作). 在某种情况下,即使存在RA,终端实体可能仍然需要和CA直接通信 例如,在RA进行登记和接 受审核,而直接与CA通信来更新证书 5.3PKI管理要求 PKI管理的要求如下: PKI管理必须符合GB/T16264.8一2005及相关修订补篇(指证书扩展项); a b PKI管理必须符合PKI系列草案的其他标准; 必须能够在不影响其他密钥对的前提下定期地更新任意密钥对; 为了使调整简单易行,在PKI管理协议中应尽可能少的使用加密; PKI管理协议必须允许使用不同的工业标准加密算法 这意味着,原则上,任何给定的CA、 RA或终端实体,可以使用任何适合其所拥有的密钥对的算法; PKI管理协议一定不能排除密钥对由相关的终端实体或RA或CA产生 密钥产生也可以在 其他地方完成,出于PKI管理的目的,我们可以认为密钥生成发生在密钥第一次出现的地方: 终端实体,RA或CA; PKI管理协议必须能够支持相关终端实体或RA、CA进行证书发布 在不同实现和不同的环 g 境下可以采用上面任何一种方法; h)PKI管理协议必须允许通过认证的终端实体请求作废证书以签发CRL 这一功能必须能够 尽可能防止拒绝服务攻击 PKI管理协议必须能够使用各种不同的传输机制,特别是邮件传输协议、HTTP,TCP/IP 和FTP; 签发证书的最终决定权属于cA RA或终端实体都不能假定CA签发出来的证书符合它们的 全部要求 cA可以根据其运营策略,改变一个证书字段的值,或者舔加、剩除、修改证书扩展 换句话说,所有的PKI实体(终端实体,RA.CA)都必须能够处理那些与其请求不一致的 项 证书响应(例如.CA可能会缩短证书有效期) CA策略可能作出规定,在证书请求者检查并 接受新签发的证书之前,CA机构不能发布或分发该证书(通常使用证书确认消息完成这一功 能) PK1管理协议必须能够支持未泄密的CA密钥对的更新即CA密钥更新) 如果CA发生膀 k 钥泄露,那么该CA所辖的全部实体都必须重新进行初始化操作 在cA密钥更新以后,PsE 中包含CA新公钥的终端实体,必须仍然能够验证使用旧的CA公钥能够验证的证书 直接 信任旧的CA密钥对的终端实体,也必须能够验证新的CA私钥所签发的证书 在某些实现或情况下,RA的功能可能会由CA来承担 PKI管理协议的设计,必须满足下面 l 的条件;终端实体不管与CA还是与RA通信都应该使用相同的协议 m)当终端实体发出的证书请求带有公钥时,必须能够证明拥有相应的私钥 完成此项工作可以 用不同方法,究竞采用哪一种取决于认证请求的类型 关于证书管理协议消息中定义的带内 方法完成以上工作的详细内容见6.3 5.4PKI管理操作 图1描述了PK1管理操作所定义的各个实体间的关系 可以沿着字母标明的线路发送PKI消息
GB/T19714一2005 证书发布 终端实体 带外方式装截 初始化注册/验证 密切对恢复 密钥对更新 证书更新 作废请求 PKI“用户” PKI管理实体 证书 CRL库 RA 证书发布 带外发布 证书发有 交叉认证 CRL发布 交又证书更新 CA-2 图1PKI实体 在上层,各种PKI操作可以按下列方式分组 CA的建立 当建立一个新的CA时,需要完成一些必要的操作(例如;发布初始CRL,导出 a CA公钥. b)终端实体初始化;包括导人根CA公钥,以及获得PKI管理实体所支持的可选项信息 认证:各种操作都将导致创建新的证书 c 初始注册和认证;终端实体在CA为它签发证书之前第一次向CA或RA表明自己的身 份 这一过程成功时的最终结果是CA为终端实体的公钥签发证书,并将该证书返回给 终端实体和/或将该证书发布到公共的数据仓库中 这一过程通常包括多个“步骤”,还可 能包括终端实体设施的初始化过程 例如,终端实体设施必须能够安全地导人CA公钥 以用来验证证书路径 此外,终端实体通常还需要导人自己的密钥对 密钥对更新;任何密钥对都需要定期更新即用新的密钥对替换旧的密钥对),因此需要签 发一个新的证书 3)证书更新;由于证书会过期,如果其他相关信息没有变化,那么证书就可以被“刷新” 4 CA密钥对更新;同终端实体一样,CA密钥对也需要定期更新,但需要不同的机制
GB/T19714一2005 5)交叉认证请求:一个CA请求另一个CA签发一个交叉证书 “交叉证书”的主体CA与 签发者CA完全不同,主体公钥信息(SubjectPublieKeylnfo)字段包含着验证密钥即该 证书是为主体CA的签名密钥对签发的) 交叉证书细致的区分时使用下面的术语;“域 间交叉证书” 如果交叉证书的主体CA和签发者CA属于不同的管理域;其他的交 叉证书则称作“域内交叉证书” 注1:上面所定义的“交叉证书"与x.509中定义的"CA证书”是并列的 注意不要把“交叉证书”同x.509中 的“cACertificate”属性相混淆,它们之间没有联系 注2除非特别说明,否则一般认为术语“交义证书"指的就是“域间交叉证书" 注3交叉证书的签发可以是相互的(但并非必须这样做)换句话说,两个CA可能彼此为对方签发交叉证书 6)交叉证书更新与普通证书更新类似,不同之处就在于它操作的是交叉证书 证书/CRL搜索操作;某些PKI管理操作将导致发布证书或CRL 证书发布:产生证书之后,就需要通过一些方法发布这些证书 PKIX中定义的方法可以 是7.3.13~7.3.16中规定的方法,或者是RFC2559、RFC2585(PKIX系列规范的“操作 协议”方案)中描述的其他方法(例如;LDAP). CRL发布:与证书发布类似 恢复操作:当一个PK1实体“丢失”它的PSE时,需要通过某些PKI操作完成恢复工作 密钥对恢复:作为可选操作,用户密钥资料例如用户的解密密钥)可以由CA,RA或与CA或 RA相关的密钥备份系统进行备份 如果一个实体需要恢复它已经备份的密钥资料例如忘 记了私钥保护密码或丢失了密钥链文件),就需要一个支持密钥恢复的协议消息 撤销操作:某些PKI操作将需要创建新的CRL条目或新的CRL 撤销请求;一个经过授权的人向CA发出异常情况警告并要求撤销证书 PSE操作;PSE操作(例如转移PSE,更改口令等)的定义超出了本标准的范围,这里我们还是 g 定义了一个PKI消息(CertRepMessage),它可以作为该操作的基础 注:在线协议并非是实现以上操作的唯一途径 对任何一个操作来说,离线方法可以达到同样的效果,本标准也并 不强制使用在线协议 例如:当使用硬件介质时,很多操作都通过物理介质的传送来完成 后面将定义一组支持以上操作的标准消息 关于在不同环境中传送这些消息的传输协议(基于文 件的、在线、Email和www)的定义,已经超出了本标准的范围,将在其他文档中单独说明 前提与限制 终端实体初始化 对于每一个终端实体,在与PKI管理实体进行交互之前,首先要申请获得一些信息,包括获得PK1 系统所支持的功能、安全获得相关根CA的公钥 初始注册/认证 终端实体的初始化让册和认证有很多种方案 由于cA执行的策略各不相同并且终端实体的类 型也有所不同,因此没有一种方案能适应所有的环境 初始化注册前,终端实体与PKI还没有任何的联系 当终端实体已经拥有认证过的密钥对时,就 可以进行简化或选择其他的方案 以下对本标准支持的初始化注册和认证方案进行分类 方案中一部分为强制性的，一部分为可选 择的 强制性的方案能够覆盖到大多数的实际应用,而可选方案满足那些不是很常用的应用 这样,在 系统的灵活性和系统实现的简便上进行了折衷 6. 2.1所用的准则 6.2.1.1注册/认证的启动 就产生的PKI消息而言,初始化注册/认证的启动发生在产生第一条与终端实体相关的PKI消息
GB/T19714一2005 的地点 可能的场所是在终端实体,RA或者CA 6.2.1.2终端实体消息的最初认证 终端实体产生的请求证书的在线消息认证与否都可以,但要求对最初终端实体发给PKICA/RA 的任何消息进行认证 在本标准中,PKI(CA/RA)通过带外方式向终端实体发放秘密数据(初始认证密钥)和参考数据 用于识别密钥)来完成 然后初始认证密钥就可以用来保护相关的PKI消息了 因此,通过判断在线消息是否经过初始鉴别从而对初始注册/认证方案进行分类 注l:本标准不讨论对PKI系统发给终端实体的消息的认证,因为在所有情况下,在终端实体设施安装根CA的公 钥或基于初始认证密钥都可 以实现这一认证 注2;如果终端实体发送的消息通过带外方式被鉴别,那么可以认为初始注册/认证流程是安全的 6.2.1.3密钥产生的地点 在本标准中,认为“密钥产生”的地点是密钥(无论是公钥还是私钥)第一次在PKI消息中出现的地 方 注意,这不排除有一个密钥集中产生的服务,密钥可以在其他地方产生,然后使用一个自定义的或 者标准的)密钥产生请求/响应协议(该协议不在本标准的讨论范围之内)导人到终端实体、RA或 CA中 密钥产生的地点有三种可能:终端实体、RA或者CA 6.2.1.4成功认证的确认 在为一个终端实体创建初始证书以后,通过让终端实体显示确认成功地接收到了包含证书(或表明 证书已生成)的消息,从而可以得到附加的保证 当然,这个确认消息必须受到保护(通过初始认证密钥 或者其他方式 这又提供了两种可能性:确认的或者未确认的 6.2.2强制的方案 上面的标准考虑到了大多数的初始注册/认证方案 要求符合本标准的CA设施、RA设施和终端 实体设施必须支持下面的第二种方案 如果需要,任何实体还可以支持其他的方案 6.2.2.1集中方案 按照上面的分类标准,这种方案可能是最简单的 启动发生在进行认证的CA; 不要求在线消息的认证; 密钥由进行认证的CA产生(见6.2.1.3); 不要求确认消息 从消息流的角度来看,本方案意味着只要求一个由cA发送给终端实体的消息 这个消息必须包 含终端实体的全部PSE信息 该消息使用加密传输,通过带外方式通知终端实体(如用电话通知消息 的保护口令),使终端实体认证并解密接收到的消息 6.2.2.2基本认证方案 按照上面的分类标准,本方案如下 启动发生在终端实体; 要求进行消息认证; 密钥由终端实体产生(见6.2.1.3); 要求确认消息 从消息流的角度来看,基本认证方案见图2
GB/T19714一2005 终端实体 RA/C'A 带外方式分发初始认证密佣(IAK)和参考数据(RA/cA->EE) 部生密钥 生成认证请求 利用IAK保护请求 -认证请求 验证请求 处理请求 生成认证响应 认证响应 处理响应 生成确认消息 -证书确认消息 验证确认消息 生成响应 确认ack(可选的 处理响应 图2初始化注册/认证基本方案 在验证证书确认消息失败的情况下,如果新签发的证书已经发布或者可以由其他的方式获得,那么 CA/RA必须撤销该证书 6.3私钥拥有证明 为了使CA和RA能够有效地验证终端实体和密钥对间的绑定是否合法,这里定义一种PKI管理 操作,终端实体可以通过这种操作证明自己拥有并能使用与申请证书的公钥相对应的私钥 一个CA/ RA在认证交换时可以自由选择如何实现POP(例如带外方式或带内方式) 目前有很多非PKIX的操 作协议(例如各种电子邮件协议),并不明确验证终端实体和私钥间的绑定;因此要求CA/RA必须通过 某种方式实现POP ,加密和密钥协商密钥对)的操作协议广泛存在之前,绑定的验 证只能被RA/CA实现 因此,没有被RA/CA验证绑定的PKI证书就会因为没有任何意义而终止 按照证书申请中的密钥对类型的不同,POP须通过不同的方式完成 如果是一个多种用途的密 钳,那么,任意一种适当的方法都可以使用(例如,如果一个密钥可以用于签名以及其他应用.那么就不 能将它送到CA/RA去验证POP) 本标准允许终端实体向RA提供相关证明,随后RA向CA说明需要的证明已经完成(并验证 例如;一个想要申请签名证书的终端实体向RA送去签名信息,RA随后通知CA终端实体已经提供了 要求的证明 当然,某些策略可能不允许这种情形(例如,CA可能是认证过程中唯一可以验证POP的 实体 签名密钥 对于签名密钥的情况.终端实体通过对一个数撮签名来证明拥有私钥 加密密钥 对于加密密钥的情况，终端实体可以将私钥提供给CA/RA,或者通过解密一段数据来证明对私钥 的拥有(见7.2.8) 解密数据可以是直接方式也可以是间接方式 直接方式是RA/CA给终端实体发送一个随机的挑战数,同时要求终端实体立即返回响应， 间接方式是给终端实体返回加密的证书(让终端实体在确认消息中证明它能解开这个证书) 这使 得只有预期的终端实体才能使用CA签发的证书 本标准鼓励使用间接方式,因为这种方式不需要发送额外的消息即可以使用消息三元组请求， 响应,确认}来证明.
GB/T19714一2005 6.3.3协商密钥 对于协商密钥的情况,为了证明终端实体拥有私钥,终端实体和PKI实体(RA或者CA)必须建立 -个共享的密钥 注意,这种方法并不需要对CA可以认证的密钥做什么限制 对于Diffie-Hellman密钥,终端 实体可以自由选择它的算法参数 只要CA在需要时可以利用适当的参数生成短期或一次性)的 密钥 6.4根CA的更新 这里只描述对某些终端实体来说是根CA的情况 这里所描述流程的基础是CA利用旧私钥保护新私钥同时利用新私钥保护旧私钥 因此,当CA 更新密钥对时,如果证书要在X.500目录服务器发布,则必须生成两个额外的cACertifieate属性值(这 样共有四个:oldwithOd,oldwithNew,newwithOld以及newwithNew). 当一个CA更改密钥对的时候,那些已经通过带外方式持有该CA旧公钥的终端实体受到的影响 最大 这些终端实体需要访问由旧私钥保护的CA新公钥 然而,它们只在一个有限的时间段需要这 一证书(直到它们通过带外方式获得新的CA公钥) 通常,当这些终端实体的证书到期的时候,这自然 便实现了 用来保护新旧CA公钥的数据结构不是新的数据结构是标准的证书结构(也可能包含扩展项) 注l:为了支持vl版本证书,目前的方案没有利用任何X.509v3的证书扩展项 密钥标识(Keyldentifier)扩展项的 存在是为了提高效率 注2，可以将这一方案进行推广,以适应CA在它的任一终端实体证书的有效期内多次更新自己密钥对的情形,但 这种推广似乎没有什么价值 不作这种推广仅仅意味着CA密钥对的有效期必须比用这对密钥签发的所有 证书的有效期都长 注3:本方案确保终端实体最晚将在它所拥有的由CA旧公钥签发的最后一个证书过期时获得CA新公钥通过带 外方法) 发生在其他时候的证书和/或密钥更新操作并不要求这一点(这依赖于终端实体设施 6.4.1CA操作员的行为 要更新CA的密钥,CA操作员要完成以下操作 a 产生新密钥对; -个用新私钥为旧公钥签名的证书" b 产生一 (“oldwithnew”证书); (“newwithold”证书) 产生 一个用旧私钥为新公钥签名的证书 C 产生一个用新私钥为新公钥签名的证书(“newwithnew”证书); d 通过数据仓库或其他方式发布这些新证书(可能使用CAKeyUpdAnn消息) 导出CA新公钥,这样终端实体就可以通过带外方式获得如果需要的话 f 旧cA私钥将不再使用 但旧cA公钥还会延续使用一段时间 当CA所属的终端实体都已经安 全地获得了CA新公钥的时候,旧公钥就不再使用了(防抵赖除外). “oldwithnew”证书的有效期必须从旧密钥生成的时间开始,到旧公钥到期的时候结束 “newwithold”证书的有效期必须从新密钥对生成的时间开始,到足以保证所有终端实体都得到 了新的CA公钥时结束(最晚到旧公钥到期的时候) “newwithnew"”证书的有效期必须从新密钥对生成的时间开始,到CA下一次更新其密钥时或CA 次更新其密钥之前结束 6. .4.2验证证书 通常在验证签名的时候,验证者要验证包含签名者公钥的证书 然而,一旦允许CA更新密钥,就 会出现很多新的可能性,如表1所示: 1o
GB/T19714一2005 表1验证签名可能情况 密钥库包含了新的和旧的公钥 密钥库只包含旧公钥(例;推迟发布 PsE包含新公伊 PsE包含旧公钥 sE包含新公钥 PsE包含旧公钥 签名者的证书情况1这是一种标准情况3，这种情况下验情况5;CA操作员没情况7在这样的情况 由新公钥来的情况,验证者不需要证者必须访问数据仓库有更新数据仓库,但验之下CA操作员没有更 保护 访问数据仓库,可以直以获得新公 证者可以直接验证证书新数据仓库,因此验证 接验证证书 与第一种情况相同 过程将会失败 签名者的证书情况2在这样的情况情况4在这样的情况情况6，验证者认为这情况8CA操作员没 由旧公钥来下,验证者要提必须访下,验证者不需要访问种情况和情况2是一样有更新数据仓库,但验 保护 问数据仓库获取旧公钥数据仓库，可以直接的,会访问数据仓库,但证者可以直接验证,与 验证 情况4相同 是验证会失败 6. 4.2.1在情况1情况4、情况5和情况8下的验证 在这样的情况下,验证者拥有CA公钥的一份本地拷贝,可以用来直接验证证书 这种情况与没有 密钥更新时是一样的 第8种情况会在CA操作员已经生成了新密钥和将新密钥导人系统之间的时候出现 当此间隙期 间CA操作员已经发布了签名者和验证者的证书的时候,情况5会出现(CA操作员要尽量避开这样的 情况 6.4.2.2在情况2下的验证 在情况2下,验证者必须得到CA的旧公钥 验证者执行下列操作 在数据仓库中查找caCertifieate属性,获得OdwithNew证书(基于有效期来判断,注意主体 a 和签发者字段必须匹配); b)利用CA新密钥(验证者本地拥有的)验证该证书是否正确; 如果正确,利用CA旧密钥验证签名者的证书 c 当cA操作员先为签名者签发了证书,更新cA密钥后,又为验证者签发证书时,会发生这种情况， 因此这是一种很典型的情况 6. .4.2.3在情况3的验证 在第3种情况下,验证者必须要取得CA的新公钥,验证者执行下列操作 在数据仓库中查找caCertifeate属性,获得NewwithOld证书(基于有效期来判断,注意主体 a 和签发者字段必须匹配); b)利用CA旧密钥(验证者本地拥有的)验证该证书是否正确; c 如果正确,利用CA新密钥验证签名者的证书 当cA操作员先为验证者签发了证书,更新cA密钥后,又为签名者签发证书时,会发生这种情况， 因此这也是一种很典型的情况 6.4.2.4在情况6下的验证失败 在这种情况下CA已经为验证者签发了包含新密钥的PSE但尚未更新数据仓库中的属性 这意 味着验证者无法得到可信赖的CA的旧密钥,所以验证失败 此失败是由CA操作员的错误造成的 6.4.2.5在情况7下的验证失败 在这种情况下,CA已经用新密钥为签名者签发了证书但尚未更新数据仓库中的属性 这意味着 验证者无法得到可信赖的CA旧密钥,所以验证失败 此失败也是由cA操作员的错误造成的 6.4.3作废 -CA密钥的改变 如上所述，一旦允许更改CA密钥,那么证书的验证将变得更为复杂 对于作废检查也存在同样的 ll
GB/T19714一2005 问题因为CA可能利用新私钥而不是用户PSE中已经存在的私钥签发CRL 对各种情形的分析与证书验证相同 数据结构 7.1PKI消息综述 本标准中所有用于PKI管理的消息都采用下面的结构 PKIMes essage::=SEQUENCE" PKIHeader， header body PKIBody PKIProtectionOPTIONAL proteetion[0叮 SEQUENCES1ZE1..MAX)OFCertificateOPTIONAL extraCerts[1] PKIMes SEQUENCESIZE(1..MAXOFPKIMes ssage ssages:: PKIHeader包含许多PKI消息公有的信息 PKIBody包含与具体消息相关的信息 PKIProtection字段是可选的,包含对PKI消息进行保护的比特串 extraCerts字段可以包含对接收者来说可能有用的证书 例如,CA或RA可以利用这一字段向终 端实体提供它验证自己的新证书时所需要的证书(例如,如果签发终端实体证书的cA对它来说不是一 个根CA) 注意,这个字段不一定包含一个证书链 为了使用证书,接收者可能需要对这些证书进 行分类、,选择或其他处理 7.1.1PKI消息头 所有的PKI消息都要求使用消息头的某些信息进行寻址和交易标识 某些同样信息也出现在与 传输相关的信封中 不管采用哪种方法,只要PKI消息受到保护,这些信息就会同样受到保护 下面的数据结构用于保存这些信息 PKIHeader;;=sEQUENCE NTEGERcmp1999(1)，cemp2000(2). pvno sender GeneralName 标识发送者 reeipient GeneralName 标识预期的接收者 [O]GeneralizedTimme OPTIONAL. messageTime 产生这个消息的时间(当发送者认为该时间的传输合适时使用 即接收方接收到消息时这个时间仍有意义 proteetionAlg[1]Algorithmldentifer OPTIONAL 用于计算proteetion比特的算法 senderKID [2]Keyldentifier OPTIONAL reeipKID [3]Keyldentifer OPTIONAL 标识用于保护的特定密钥 transaetionlD[4]OCTETSTRING OPTIONAL 标识交易;即在相关的请求、响应和确认消息中,该字段值相同 [5]0cTETsTRING OPTIONAL senderNonce [6]0CTETSTRING OPTIONAL recipNonce -用于防止重放攻击的随机数,senderNNonce由消息的创建者赋值 12
GB/T19714一2005 reeipNonce是由本消息的预期接收者先前插人到相关消息中的随机数 freeText [7]PKIFreeText OPTIONAL 可以用于表示上下文相关的说明(本字段主要由人工使用 generallnfo [8]SEQUENCES1ZE(1..MAX)OF lnfoType.AndValue OPTIONAL 可以用于表示上下文相关的说明(本字段不是供人工使用的) PKIFreeText::=SEQUENCEsIZE(1..MAX)OFUTF8String -按UTF-8[RFC2279]编码的文本(注意;每一个UTF8String都可以包含 一个RFC1766/RFC3066语言标签,用于表示所包含文本属于哪一种语言 详情请参见RFC2482 对于该版本pvno字段取固定值2 sender字段包含PKIMessage发送者的名字 这个名字(与senderkKID一起,如果提供的话)应当 能够标识出对这一消息的保护进行验证所需要的密钥 如果发送方实体并不清楚自己的任何信息(例 如;在初始化请求消息中,终端实体并不清楚自已的DN,电子邮件、IP地址等),那么“eendler" -”字段必须 包含一个“NULL”值;即一个长度为0的SEQUENCEOF 在这种情况下,senderKID字段必须包含 个标识符(即一个参考数),这个标识符能够向接收者表明验证消息所用的共享密钥信息 reeipient字段包含PKIMessage接收者的名字 这个名字(与recipkKID一起,如果提供的话)应当 可以用于验证对消息的保护 protection.Alg字段指明保护消息所用的算法 如果没有提供保护比特位(注意PKIProtection是 可选的),那么必须省略这个字段;如果提供了比特位,那么必须提供这个字段 senderKID和reeipKID用于标识使用了哪个密钥保护消息(reeipkID通常仅在使用Diffie-Hell- man密钥保护消息时才要求) 如果要求唯一标识一个密钥就必须使用这些字段(例如;如果一个发送 者的名字与多个密钥相关联),否则就应当省略这些字段 transaetionID字段用于使消息的接收者将这个消息与以前签发请求相关联 比如对于RA,trans- acetionID可以将某消息与同一时刻众多消息区分开来 enderNonce和recipNNonce字段保护PKIMessage免受重放攻击 geTime字段包含发送者创建这个消息的时间 可以由终端实体用于校正:/检查自已的本地 message 时间以便与中央系统的时间保持一致 freText字段可以用于发送一个人可读的消息给接收者(用任意多种语言) 这个序列中的第一种 语言表明响应期望使用的语言 generallnfo字段可以用于向接收方发送机器可读的额外的数据 可以支持下面定义的generalln fo扩展项 7.1.2PKI消息体 PKIBody::=CHOICE--与消息类型相关的消息体和参考章条 [o] CertIReqMessages --初始化请求(7.3.1 [ CertRepMessage" --初始化响应(7.3.2 i [2 CertReqMessages --认证请求(7.3.3) cr [3灯 CertRepMessage, -认证响应(7.3.4) cp [村 CerifieationReqest, pl0er --PKCs井10认证请求[PKCs10] popdecc[时 POPODeckKeyChalCo --POP挑战(7.2.8) ontent [6叮 POPODecKeyRespContent，--POP响应(7.2.8) popdecr 13
GB/T19714一2005 kur [7] ertReqMessages -密钥更新请求(7.3.5) kup [8灯 CertRepMessage" -密钥更新响应(7.3.6 kr [9] CertReqMessages、 -密钥恢复请求(7.3.7 d krp [10KeyReeRep -密钥恢复响应(7.3.8) ontent [I]RevRegContent. -作废请求(7.3.9) r [12 RevRepContent -作废响应(7.3.10) rp [13 CertRe RepMt -交叉认证请求(7.3.11 lessages, ccr cerRpMe [1n 交叉认证响应(7.3.12) essage， ccp [a5 ckuannm CAKeyUpdAnnContent. -CA密钥更新公告(7.3.137 [1的 CertAnnContent -证书公告(7.3.l4 cann [1刀 RevAnnContent， -作废公告(7.3.15) rann [187 CRLAnnContent crlann -CRL公告(7.3.l6) [19 PKIConfirmContent， -确认(7.3.17 pkiconf [20 nested NestedMessageContent -嵌套消息(7.1.3 [21]GenMsgContent -通用消息(7.3.19) genm [22] GenRepContent -通用响应(7.3.20 genp [237 ErrorMsgContent， -错误消息(7.3.21) errOr erCon[24 --证书确认(7.3.18 CertConfirmContent， 25 pollReg PolIRegContent --轮询请求(7.3.22) pollRep [26 PollRepContent -轮询响应(7.3.22 每一 -种类翠将在了.3中描进 7.1.3PKI消息保护 某些PKI消息需要保护完整性 (注意如果使用非对称算法保护消息并且相应公钥部分已经被 认证,那么消息的来源也可以被证明 另一方面,如果公钥部分未被认证,那么消息来源不能自动被证 明,但可以通过带外方式被认证 protection的结构如下 PKIProtection;;=B1TsTRING 计算PKIProtection时输人的是下面数据结构的DER编码 SEQUENCE ProtectedPart:: headerPKIHeader. PKIBody body 在有些情况下,采用PKIX以外的其他保护方法保护消息,而不采用PKIProteetion比特串即省略 这个可选的字段) 本标准允许选择这种方法 这种外部保护的例子包括使用PKCS井7[PKCS7]或 SecurityMultiparts[RFC1847]对PKIMessage封装(当PKIHeader信息由外部机制安全的传输时,仅 对省略CHOCE标签的PKIBody进行封装) 然而需要注意的是,许多这样的外部机制要求终端实体 已经拥有一个公钥证书和/或一个唯一的DN和/或其他与基础结构相关的信息 这样,这些方法对于 初始注册、密钥恢复或其他具有“初始引导”特性的过程来说就不合适 对这些情况,可能必须使用 PKIPr Protection 将来,当修改后的外部机制可以适用于具有“初始引导”特性的场景时,PKIProtectionm 将会变得很少或根本就不再使用 根据环境不同,PKIProtection比特可以包含一个消息认证码MAC)或数字签名 只有下面的儿 种情况 14
GB/T19714一2005 共享密钥信息 a 在这种情况下,发送方和接收方共享(通过带外方法或前一个PKI管理操作建立的)密钥信 PKIProteection将包含一个MAC值,protectionAlg如下(参见附录B): idPasswordBasedMacOBECTIDENTIFIER;;=(12840113533766131 PBNMParameter;=SEQUENCE OCTETSTRING. salt Algorithmldentifier, owt -散列函数算法标识 ountINTEGER. iterationco OwF的应用次数 N lgorithmldentifer mac MAC算法标识 在上面的protectionAlg中,在共享密钥的后面将追上sal值 然后应用iterationCount次 OwF算法,其中,追加了salt值的密钥作为第一次迭代的输人,对后续的每一次迭代,其输人 都是前一次迭代的输出 最后一次迭代的输出为了方便引用称作“BASEKEY”,其长度为 “H”)用于形成对称密钥 如果MAC算法要求一个K-比特的密钥而且K<=H,那么密钥 就取BASEKEY的前K比特 如果K>H,那么BAsEKEY的全部H比特将作为密钥的前 H比特,OwF(“1”BASEKEY所得结果将作为密钥的下一H比特,OwF(“2” BASEKEY所得结果将作为密钥的再下一H比特,依此类推,直到得到所有的K比特为止 这里,“NN”代表数字N的AsSC字节编码,“II”代表串联 注:建议PBMParameter字段在一个交易的所有消息中(例如ir/ip/certConf/pkiConf)保持不变,这样可 以降低计算！ PasswordBasedMac的负荷 b)非对称密钥对 使用非对称密钥算法进行消息保护,下面以DH算法为例说明: 当发送者和接收者拥有相容的DH参数的DH证书时,为了保护消息,终端实体必须基于自 己的DH私钥值和PKI消息接收方的DH公钥值产生一个对称密钥 PKIProtection将包含 由这个对称密钥计算出的MAC值,proteetionAlg如下 1284011353376630" id-DHBasedMacOBECTIENTIFIER::一 DHlBMParameter;=SEQUENCE Algorithmldentifier owf 散列函数算法ID mac Algorithmldentifier MAC算法ID 在上面的proteetionAlg中,对DH计算的结果应用OwF OwF的输出为了方便引用称作 “BASEKEY”,其长度为“H”)用于形成对称密钥 如果MAC算法要求一个K-比特的密钥而 且K H,那么密钥就取BAsEKEY的前K比特 如果K>H,那么BASEKEY的全部 H比特将作为密钥的前H比特,OwF(“1”BASEKEY)所得结果将作为密钥的下一H比 特,owF(“2”IIBASEKEY所得结果将作为密钥的再下一H比特,依此类推,直到得到所 有的K比特为止 这里,“N”代表数字N的AsCI字节编码,“I”代表串联 签名 在这种情况下,发送方拥有一个签名密钥对,对PKI消息进行签名即可 PKIProtection将包 15
GB/T19714一2005 含签名值,proteetion.Alg为一种用于数字签名的算法 多重保护 当终端实体发送一个保护的PKI消息到RA,RA可以追加自己的保护(可以是MAC或签名 取决于RA和CA之间共享的信息和证书)后将消息转发到CA 这种保护通过将终端实体发 送的消息整个嵌套到一个新的PKI消息中实现 使用的结构如下: NestedMessageContent;;=PKIMessages 7.2公共数据结构 在定义PKIBody中的特定类型之前.我们先定义一些多处使用的数据结构 7.2.1被申请的证书内容 各种PK1管理消息都要求消息的发起者指明证书里存放的某些字段的值 CertTemplate结构体 使得EE或者RA可以尽可能地指定它们所希望申请到的证书里的内容 CertTemplate结构体与证书 的内容完全一致,但所有的字段都是可选的 注:即使消息的发起者指明了它所申请的证书的所有内容,CA机构仍然可以自由改动实际发放的证书的字段值 如果申请者不能接受被修改后的证书,那么申请者必须回送一 -个cerCon消息,其中或者不包括该证书(通过 个CertHash),或者包含该证书通过一个CertHHash)但同时状态置为“rejeeted” CertHash和certCon消息 的定义以及使用参见7.3.18 CertTermplate语法见附录D及RFC2511 7.2.2加密值 在KI消息中发送加密值(在本标准中,加密值限于私钥或者证书时采用EimerypteYdle数据结 构 EneryptedValue的语法见RFC2511 使用该数据结构要求创建者和期望的接收者分别都能够进行加密和解密操作 典型情况下,这意 味着发送者和接收者拥有,或者能够产生共享的秘密密钥 如果PKIMessage的接收者已经拥有用于解密的私钥,则eneSymmkKey字段可以包含用接收者的 公钥加密的会话密钥(sessionkey). 7.2.3PKI消息的状态编码和失败信息 所有的响应消息都包含某些状态信息 下面定义了相应的值 INTEGER PKIstatus:一 accepted 0) 表示得到了所要求的数据 grantedWithMods 1)， 得到的数据与所要求的类似,但申请者有责任确定有无差别 rejection 2) 无法得到的数据,在该消息的其他地方有更多的信息 3). waiting 请求的包体尚未被处理,期望稍后将获取结果(注意:对具有该状态的响应,恰当的处理方式 可以是使用3.3.22中定义的轮询请求/响应PKIMessages;使用底层的传输层轮询机制 一种可行的方法" 也是 revocationwar 4. arning 本消息包含一个即将作废的警告信息 revocationNotification5)， 通知已经作废 16
GB/T19714一2005 6 keyUpdatewarning 在密钥更新请求消息中oldCertld指示的密钥已经更新 响应者可以使用下列语法以提供有关失败状况的更多信息 PKIFailurelnfo;;=BITSTRING -因为多种情况可能导致失败,所以在需要时可以加人更多的代码 0) badAlg 不可识别或者不支持的算法标识符 badMes heck sgecchn 完整性检查失败(例如,签名验证不成功) 2 badRequest 不允许或不支持的交易 badTime 3 根据本地策略,请求中的; messageTime与系统时间不够接近 badCertld 4) 无法找到与提供的条件匹配的证书 badDataFormat 5 提交的数据格式错误 wrongAuthority 6). 请求中指明的权威机构与本响应的创建者不同 incorrectData 7)， 申请者的数据错误(用于公证服务 missingTimeStamp 8)， 在要求存在时戳的时候没有提供(根据策略要求 badPOP 9 拥有证明失败 PKIStatusInfo;;=SEQUENCE PKIStatus. status PKIFreText OPTIONAL. statusString ailnfo PKIFailurelnfo OPTIONAL 7.2.4证书标识 Certld数据结构用于鉴别特定的证书 Certld的语法见RFC2511 7.2.5“带外”根证书公钥 每个根CA必须能够通过一些“带外”方式来发布它的当前公钥 虽然这样的方法不在本文描述的 范围之内,我们定义了支持这种方法的数据结构 -般而言,有两种可能的方法:CA机构直接发布它的自签名证书;或者可以通过目录服务器(或其 他类似方式)获得自签名证书,同时CA发布自签名证书的哈希值用于由使用者)在使用(CA证书)之 前进行完整性校验 OOBCert::=Certifcate 该证书中的值域有如下限制 n
GB/T19714一2005 证书必须是自签名的即,签名必须可以用SubjeetPublickeylnfo中的值来验证): 主体字段和签发者字段的值必须完全相同 如果主体字段为空,则主体可替换名和签发者可替换名扩展项必须同时存在,并且具有完全 相同的值 所有其他扩展项的值必须符合自签名证书的要求比如,主体和签发者的密钥标识符必须完 全相同 OoBCertHash:;=SEQUENCE" hashAlg [0]Algorithmldentifier OPTIONAL OPTIOAL， erld [1]Certld hashVal BITSTRING ashVal是对由certID所标识的自签名证书进行运算得出的值 has 散列(哈希)值的目的在于:任何(通过带外方式)安全获取到散列哈希值的用户都能验证该CA 的自签名证书 7.2.6归档选项 请求者可以用PKIArchiveOptions结构体来指明它们希望PKI归档某私钥 PKIArchiveOptions的语法见RFC251 7.2.7发布信息 请求者可以用PKIPubicationlnfo结构体来指明它们希望PKI发布证书 PKIPublicationlnfo的语法见RFC2511 7.2.8拥有证明结构体 如果是为签名密钥对申请证书(即申请一个验证证书),则可以使用POPOSigningKey结构体来证 明对签名私钥的拥有 POPOSigningKey的语法见附录D及RFC2511,但注意本标准中POPOsigningKeylnput存在下 面的语义约定: POPOSi igningKeylnput::=SEQUENCE authlnfo CHOICE [o]GeneralName. sender 取自PKIHeader(仅当发送者的身份鉴别已通过某种方式(如以前发布的、当前处于有效状态的 证书中的DN)建立之后使用 publiekeyMAC PKMACValur 发送者当前没有已鉴别通过的通用名(GeneralName)存在时使用;publieKeyMAC包含一个 基于口令的针对公钥的DER编码的MAC值(使用PKIHeader中的protectionAlg算法标识) pubieke SubjeetPublieKeyInfo ey 取自CertTemplate 另一方面,如果为加密密钥对申请证书(即申请一个加密证书),则可以使用下列三种方式之一来证 明对解密私钥的拥有 通过在证书请求中包含加密后的私钥在PKIArchiveOptions控制结构体中) a b)CA不直接返回证书,而是返回加密后的证书即,返回的证书用一个随机产生的对称密钥加 密,而对称密钥本身用证书请求中包含的公钥来加密) 这是6.3.2中提到的“间接”方式 18
GB/T19714一2005 终端实体通过使用源自该对称密钥的密钥计算PKIConfirm消息的MAC值,来向CA机构证 明它拥有解密私钥 当PKIMessage消息中包含不止一个CertReqMsg证书请求,并且每个 s ReqMsg使用不同的对称密钥时,MAC计算使用源自所有这些对称密钥的一个密钥.)计 O 算MAC的操作使用7.1定义的P asswordBasedMacAlgld. R Ce 和 让EE在CertReqMessages epMessage之间参与挑战一响应协议使POPODecK eT eyChal和POPODeckKeyResp消息;参照下文 这是6.3.2中提到的“直接”方式 这种 方式典型的应用环境是RA验证POP,然后代表终端实体向CA发送认证请求 在这种情况 下,CA相信RA在为终端实体申请证书之前已经正确地验证了POP.)完整的协议如下所示 注意req不一定要将req封装为嵌套消息): CA EE RA reg chall reSp reg rep conf ack rep conf ack 这一协议显然比前面的方式2中给定的3次交换要长但它允许本地注册机构(LRA)介人,并使 得POP验证通过之前并不真正生成证书 如果为密钥协商密钥对(KAK)申请证书,则POP的验证可以使用对加密密钥对验证的三种方式 中的任何一种,但要做下列变化:(1前面描述的第二种方式中的括号中的文本变为:(即,证书由根据 CA的KAK私钥和认证请求中的公钥生成的对称密钥加密);2)下面Challeng结构描述中的chal lenge字段的第一个括号中的文本改为;(使用PreferredSymmAIlg(见7.3.18)和一个对称密钥该密钥 基于CA的KAK私钥和认证请求中的公钥而产生) 此外,如果CA已经拥有一个为终端实体所知的 DH证书,POP可以使用RFC2511中定义的POPOsigningKey结构体(其中,alg字段取值为DH BasedMAC,签名字段取值为MAC)作为证明POP的第四种方式 用于解密私钥POP的挑战一响应消息定义如下 注意,挑战一响应交换通过PKIHeader中的 transactionID以及对PKIMessage的保护(MAC或签名)与前面的认证请求消息(以及后续的认证响应 和确认消息)相关联 POPODeckeyChallContent;;=SEQUENCEOFChalenge 每个加密密钥认证请求对应一个Challenge(次序与请求出现在CertReqMessages中的次序保持 -致) Challenge::=SEQUENCE AlgorithmldentifierOPTIONAL owi 在第一个Challenge中必须存在;而在POPODeckKeyChallContent随后的Challenge中可以省略 -(如果省略的话,则使用前一个Challenge中的owf字段 OCTETSTRING， witness 对随机产生的整数A应用单向函数(owf)的结果 注意每个Challenge都必须使用不同的整数 19
GB/T19714一2005 dhallenge OCTETSTRING 加密后的Rand使用认证请求中的公钥加密),Rand定义如下 Rand;=sEQUENCE tINTEGER、 int 上面提到的随机产生的整数A senderGeneralName 发送者的名称(与PKIHeader中的相同 SEQUENCEO)FINTEGER POPODeckKeyRespContent :: 每个加密密钥认证请求对应一个整数这些整数的顺序与请求出现在CertReqMessages中的顺 序保持一致) 收到的整数(上面提到的A)被返回给相应Challenge的发送者 7.3与操作相关的数据结构 7.3.1初始化请求 个初始化请求消息的PKIBody包含的是一个CertReqMessages数据结构体,这个结构体详细说 明了所请求的证书 通常,可以为每一个申请的证书提供下列模板字段:SubjectPublicKeyInfoKeyld 和Validity详细信息参见附录B) 此消息用于实体在PKI体系中的最初初始化 CertRegMessages es的语法见附录D及RFC2511 7.3.2初始化响应 数据结构体,这个结构体对应每 个初始化响应消息的PKIBody包含的是一个CertRepMessage 个证书请求均包括一个PKIStatusInfo字段、一个主题证书及可能存在的一个私钥(这个私钥通常由会 话密钥加密,而会话密钥本身由protocolEnerKey来加密》. CertRepMessage的语法见7.3.4 如果PKI消息的保护方式是“共享秘密信息"(见7.1.3),则ee- Pubs字段内的任何证书都可以被消息发起者作为根CA证书来直接信任 7.3.3注册/认证请求 个注册/认证请求消息的PKIBody包含的是一个CertReqMessages数据结构体,这个结构体详 细说明了所请求的证书 当已存在于PKI体系中实体想获取额外的证书时使用此消息 CertReqMessages的语法见附录D及RFC2511 作为可选择,PKIBody也可以包含一个CertificationRequest结构体(此结构体在[PKCs10]的 AsN.1结构CertifieationRequest部分有完全详细的说明) 当需要与早期系统进行一些交互操作时. 申请签名密钥证书的请求中可以使用该结构体,但不是绝对必要的情况下建议不使用此结构体 7.3.4注册/认证响应 个认证响应消息的PKIBody包含的是一个CertRepMessag数据结构体,这个结构体包含了与 每个证书请求对应的状态值,同时根据情况还可能包含一个CA的公钥,失败信息、一个主题证书和一 个加密后的私钥 CertRepMessage;;=SEQUENCE caPubs[1]SEQUENCEsSIZE(1..MAXOFCertifeateOPTIONAL responsesEQUENCEOFCertResponse CertResponse;=sEQUENCE ertReqld INTEGER. 使用此项使响应与请求对应若相对应的请求中未指明cerIReqld,则此项应填-1 Info， PKIstatusl status 20
GB/T19714一2005 d certifiedKeyPair ertifedKeyPairOPTONAL 0cTETSTRINGOPTIONAL rsplnlo 类似于RFC2511中CertReqMsg结构中为reglnfo定义的id-reglnfo-utf8Pairs字符串 CertifiedKeyPair;;=SEQUENCE certOrEncCert CertOrEncCert lueOPTIONAL privatekey [oEarypedval 参见RFC2511中编码的说明 pubiceationlnfo[1]PKIPubieationlnfooPIIONAL CertOrEncCert:;: CHOICE certificate 01Certificate tneryptecdcer EneryptedlValue 在每个CertResponse中failnfo(在PKIStatuslnfo中)和certifieate(在CertifiedKeyPair中)两个 字段只能出现一个(取决于状态) 在某些状态值(例如;waiting)的情况下,两者都不会出现 给定了EncryptedCcert和相关的解密私钥就可以获得证书 这种方式的目的是允许CA返回证书 值,但只有预期的接收者才能够获得实际的证书 这种方法的好处在于CA在无法证明请求者就是拥 有相应私钥的终端实体的情况下依然可以返回证书(注意;直到CA收到返回的PKIConfirm消息后才 能证明 因此,在POP验证出错时CA并不是必须作废该证书 7.3.5密钥更新请求内容 密钥更新请求使用CertReqMesages语法结构 通常,可以为每一个要更新的密钥提供下列模板 字段;SubjeetPublickKeyIlnfo，Keyld及Validity 这个消息用于请求更新已存在的证书(未作废且未过 期) 该操作有时被称作“证书更新”操作 所谓更新证书就是使用新的公钥或以原有公钥的证书替换 现有的证书 CertReqMessages的语法见附录D及RFC2511 7.3.6密钥更新响应内容 密钥更新响应使用CertRepMessage语法结构 该响应与初始化响应相同 CertRepMessage的语法见7.3.4 7.3.7密钥恢复请求内容 密钥恢复请求的语法与初始化请求中的CertReqMessages相同 通常,可以为一个签名公钥申请 证书时提供下列模板字段;SubjeetPublicKeylnfo和Keyld进一步的信息见附录B). CertReqMessages的语法见附录D及RFC2511 注意;如果需要密钥历史,请求者必须在请求消 息中加人协议加密密钥 7.3.8密钥恢复响应内容 密钥恢复响应使用下列语法 对于某些状态值(如:waiting),所有的可选项均不会出现 KeyRecRep(Content:=sEQUENCE PKIStatusInfo status newSigCert [o] Certifeate OPTIONAL [1] SEQUENCES1ZE1..MAX)OFCertifieateOPTIONAL caCerts keyPairHist [2] SEQUENCES1ZE1..MAX)OF CertifiedKeyPairOPTIONA 21
GB/T19714一2005 7.3.9撤销请求内容 当请求撒销一个证书(或多个)时,使用下列数据结构 请求者的名字出现在PKIHeader结构 体中 RevReqContent:;=sEQUENCEOFRevDetails RevDetails:;=SEQUENCE certDetails CertTemplate， 允许请求者尽可能多的提交请求撤销的证书的资料 例如;在无法获得序列号的情况下) crlEntryDetails Extensions OPTIONAL 所请求的crlEntryExtensions 7.3.10撤销响应内容 撤销响应是对上述消息的响应,生成该响应后将发送给撤销请求者 可以向请求作废证书的拥有 一个撤销公告消息》. 者发送 ent::=SEQUENCE RevRepConr SEQUENCESIZE1..MAXOFPKIStatusInfo. status 与RevReq(Content中发送的顺序相同 [0] evCerts SEQUENCESIZE(1.MAX)OFCertldOPTIONAL. 撤销请求的IDs(与status的顺序相同 [1] SEQUENCESIZE(1..MAX)OFCertificateListOPTIONAL erls 结果CRL可能不止一个) 7.3.11交叉认证请求内容 交叉认证请求与一般认证请求使用的语法相同(CertReqMessages),但具有下列限制:密钥对必须 由请求CA产生且私钥一定不能发送给响应CA 这个请求也可以用于子CA请求父CA为其签发的 证书 CertReqMesages的语法见附录D及RFC2511 7.3.12交叉认证响应内容 交叉认证响应与一般认证响应使用的语法相同(CertRepMessage),其约束是不会发送加密的 私钥 CertRepMessage的语法见7.3.4 7.3.13CA密钥更新公告内容 当CA更新了自己的密钥对后,可以使用下列数据结构宣布这一事件 CAKeyUpdAnnContent::=SEQUENCE oldwithNew 用新私钥签名的旧证书 Certificate, 用旧私钥签名的新证书 newWithOld Certificate， newWithNew Certificate,--用新私钥签名的新证书 7.3.14证书公告 这个结构体可以用于公告证书的存在 CertAnnContent;;=Certifieate 注，此消息适用于没有其他证书发布方法的情况;对于利用x.500目录服务发布证书等情况不建议使用此消息 22
GB/T19714一2005 7.3.15撤销公告 当CA已撤销或即将撤销一个证书时,可以公告这一事件(或将要来临的事件) RevAnnContent:;=SEQUENCE PKIStatus, status certld Certld wilBeRevokedAt Generalizedime. badSinceDate GeneralizedTime， crlDetails ExtensionsOPTIONAL 额外的CRL.细节(如;crl序列号、作废原因、位置等 CA可以使用这个消息来警告(或通知)一个证书持有者它的证书将要(或已经)被撤销 这主要用 于撤销请求来自于非证书持有者的情况 wilBeRevokedAt字段包含的是一个新的条目将加人到相应CRLs的时间 7.3.16CRL公告 当CA签发了一个新的CRL(或一批CRL)时,可以使用以下数据结构宣布这一事件 CRLAnnCo ontent:;=sEQUENCEOFCertifieateList 7.3.17PK确认内容 这个消息在协议数据交换中作为最后的PKIMessage 由于PKIHeader中已包含了所有必需的消 息,所以它的内容为空 PKIConfirmcontent::=NULl. 7.3.18PKI通用消息内容 ;;=SEQUENCE InfoTypeAndValue infoType OBECTIDENTFIER infoValue ANYDEFINEDBYinfoTypeOPTIONAL nfoTypeAndValue的内容包含但不限于下列值(更多的绀节见后续章条 语法描述见附录F): CAProtEncCert 'id-it1}，Certificate SignKeyPairTypes idit2)，SEQUENCEOFAlgorithmldentifier EnckKeyPairTypes idit3)},SEQUENCEOFAlgorithmldentifier PreferredSymm.Alg idit4}，Algorithmldentifer CAKeyUpdatelnfo id-it5}，CAKeyUpdAnnContent CurrentCRL id-it6}，CertificateList 其中,idit}=idpkix4=13615574,这个构造也可用于定义 新的PKIX证书管理协议的请求和相应消息或通用目的消息(例如公告 以满足未来或特定环境的要求 GenMsgCon tent= sSEQUENCEOFInfoTypeAndValue EE,RA，或者CA都可以发送该消息(取决于消息的内容) 对于上面的给出的某些例子,GenMsg 中InfoTypeAndValue的可选参数infoValue通常会被省略(即它只应用于相关的GenRep消息 中) 接收方有权忽略它不能识别的对象标识符 如果消息由EE发往CA，若结构内容为空的 表明CA可以发送其希望发送的任意或所有信息 23
GB/T19714一2005 7.3.19PKI通用响应消息 GenRepContent:;=sEQUENCEoOFInloType.AndValue 接收方可以忽略其不能识别的OID 7.3.20错误消息内容 ErorMsgContent;=SEQUENCE PKIStatusInfo. pkKIStatusInfo errorCode INTEGER OPTIONAL 与实现相关的错误码 errorDetails PKIFreeText OPTIOAL 与实现相关的错误描述 必需的PKI管理功能 8.1根CA初始化 新建立的根CA要求能够产生自己的自签名证书,这个证书结构与根CA密钥更新后发布的“new- WithNew”证书结构相同 为了使CA自己的证书对的自签名证书对那些不通过带外方法来获得这个证书的终端实体有用， CA要为它的公钥产生一个指纹 终端实体通过带外方法安全地获得这个指纹，然后就可以验证CAN 的证书以及证书里面的其他属性 传递指绞的数据结构是O)OBCertHash 根CA密钥更新 cA密钥(与其他的所有密钥一样)的生命期是有限的,因此需要进行周期朋性的更新 CA发布ne wwithNew，newwithold，和olawithNew证书(见G.4.1)用以帮助现存的终端实体将拥有的自签名 CA证书(oldwithold)安全地转变为新的自签名cA证书(newwithNew).同时也帮助新的即将获得 newwithNew证书的终端实体安全地取得oldwitho)d证书来验证现存的数据 下级cA初始化 从PK1管理协议的角度来看,下级CA的初始化与终端实体的初始化是一样的 唯一的区别在于 下级CA必须同时产生初始的撤销列表 8.4CRI产生 新建立的CA(它能发布CRL)在发布证书之前必须首先产生空的CRL 8.5PKI信息请求 当PK1实体(CA,RA,或EE)希望获得关于CA当前状态的信息时,它可以向CA发送对这种信息 的请求 CA必须向请求者提供至少请求者要求的所有请求的信息 如果某些信息不能提供,则必须 给请求者返回错误 如果使用PKI消息来请求和提供PK1相应的信息,那么请求必须使用GenMsg消息,响应使用 GenRep消息,错误使用Error错误消息 这些消息使用基于共享秘密信息的MAC(如:Password- BasedMAC)或者其他认证方法(如果终端实体拥有证书)来进行保护 在证书撤消请求中使用共享秘密信息的安全机制参见附录E 8.6交叉认证 请求者CA作为交叉证书的主体,而响应者CA作为交叉证书的发布者 请求者CA在发起交叉认证操作之前必须已建立并在运行中 交叉认证方案基本上是单向的操作;也就是说,当成功时,这个操作会导致一个新的交叉证书的产 生 如果需要产生“双向”的交叉证书,那么每一个CA都要发起一个交叉认证操作(或者使用另一种方 24
GB/T19714一2005 案) 这个方案适合于下面两种情况;两个CA已经验证过对方的签名(它们有共同的信任点);或者能对 认证请求起源进行带外验证 详细描述: 交叉认证由作为响应者的CA发起 作为响应者的CA管理员鉴别它想交叉认证的CA,同时由响 应者CA设备产生授权码 响应者的CA管理员用带外方法把授权码传递给请求者的CA管理员 请 求者的CA管理员在请求者CA处输人授权码来发起在线交换 授权码用于认证和完整性目的验证 它是这样实现的;利用授权码产生对称密钥,然后使用此对称 密钥对所有的交换消息产生消息认证码(MAc) 如果CA可以通过某些方法检索和验证请求的公 钥,那么认证也可以通过使用签名来代替MAC 请求者CA用一个新的随机数(请求者随机数)产生交叉认证请求(cer)以发起交换 然后,请求者 CA给响应者CA发送ccr消息 消息字段使用基于认证码的MAC来防止修改 收到cer消息之后,响应者CA验证消息和MAC,保存请求者随机数,并且产生自己的随机数响 应者随机数) 然后产生(如果需要就存档)一个新的包含请求者CA公钥的请求者证书,同时用响应者 CA签名私钥进行签名 响应者CA用交叉认证响应(eep)消息进行响应 消息中的字段使用基于认证 码的MAC来防止修改 收到cep消息之后,请求者CA验证消息(包括收到的随机数)和MAC 请求者CA用certConf消 息进行响应 消息中的字段使用基于认证码的MAC来防止修改 请求者CA把请求者的该交叉认 证)证书写人证书库为今后的证书路径构建提供帮助 收到certConf消息之后,响应者CA验证消息和MAC,同时使用PKIConfirm消息发回一个确认 它也会公布请求者的(交叉认证)证书为今后路径构建提供帮助 er消息必须包含一个“完整”的认证请求,也就是说,请求者CA必须规定好除了序列号的所有的 字段(包括,例如;BasicConstraints扩展) ccp消息应该包含响应者CA的验证证书一如果存在,请求 者CA必须验证这个证书(例如,通过带外机制) 可以设想一种更为简单的非交互式的交叉认证模型,在这个模型中发布者CA从证书库中获得主 体CA的公钥,并通过带外机制进行验证.然后产生和公布交又证书而不需要主体CA的参与 在很多 环境中这个模型是非常合理的,但是因为它不需要任何协议消息交换,所以详细描述不在本标准的范围 之内 交叉认证的消息结构见附录C 终端实体初始化 8. 和CA一样,终端实体也需要初始化 终端实体的初始化至少有两个步骤 获得PKI信息 对根CA公钥的带外验证 可能还会有别的步骤,包括检索信任条件信息和对别的CA公钥的带外验证 8.7.1获得PK1信息 需要获得的信息 当前根CA的公钥 假如认证CA不是根CA)包括适当的撒销列表的从根CA到认证CA以及适当的撒销列表 的认证路径; 认证CA支持的每一种相关应用的算法和算法变量 为了能产生一个成功的认证请求可能需要一些附加的信息(例如;支持的扩展或者CA策略信息 然而,为了简单化我们不强制终端实体通过PKI消息获得这些信息 最终的结果有可能导致一些认证 请求的失败(例如,如果终端实体想产生自己的加密密钥但是CA不允许) 需要的信息可以按照8.5所描述的来获得 25