GB T 19714-2005 信息技术安伞技术公钥基础设施证书管理协议.pdf

《GB T 19714-2005 信息技术安伞技术公钥基础设施证书管理协议.pdf》由会员分享，可在线阅读，更多相关《GB T 19714-2005 信息技术安伞技术公钥基础设施证书管理协议.pdf（60页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.100.70一一L 79药日中华人民共和国国家标准GB/T 19714-2005信息技术安全技术公钥基础设施证书管理协议Information technology-Security technology-Internet public keyinfrastructure-Certificate management protocol2005-04-19发布2005-10-01实施TT/v To臀嘘R Mr m臀 InJ发布 GBJT 19714-2005oli胃本标准是依据IETF RFC 2510制定的。本标准凡涉及密码算法相关内容，按国家有关法规实施。本标准中引用的RSA,

2、SHAI,DH密码算法均为举例性说明，具体使用时均须采用国家商用密码管理委员会批准的相应算法。本标准的附录B、附录C、附录F为规范性附录，附录A、附录D、附录E、附录G为资料性附录。本标准由中华人民共和国信息产业部提出。本标准由全国信息安全标准化技术委员会（TC260）归口。本标准主要起草单位：北京创原天地科技有限公司、中国电子技术标准化研究所。本标准主要起草人：林雪焰、吴志刚、王炳艳、陈震琦、张科研、李丹、罗锋盈、陈星。GB/T 19714-2005引言本标准描述了公钥基础设施（PKI)证书管理协议，定义了与证书产生和管理相关的各方面所需要的协议消息，主要包括：申请证书、撤销证书、密钥更新、

3、密钥恢复、交叉认证等等。公钥基础设施中总共有四类实体：CA, RA、终端实体、证书CRL库，如何保证四实体之间的通信安全、在证书业务中如何对四类实体进行管理，这些问题是本标准解决的主要问题。 GB/T 19714-2005信息技术安全技术公钥基础设施证书管理协议1范围本标准描述了公钥基础设施（PKI)中的证书管理协议，定义了与证书产生和管理相关的各方面所需要的协议消息，这些消息主要包括申请证书、撤销证书、密钥更新、密钥恢复、交叉认证等。本标准主要适用于在安全或不安全环境中实施PKI组件并实施管理，可作为PKI运营机构、PKI组件开发者的参考指南。2规范性引用文件下列文件中的条款通过本标准的引用

4、而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB/T 16264. 8-2005信息技术开放系统互连目录第8部分：公钥和属性证书框架（G SO/IEC 9594-8：2001，IDT)RFC2511因特网X. 509公开密钥基础设施证书消息格式3术语和定义下列术语和定义适用于本标准。3.1抽象语法记法一（ASN. 1) Abstract Syntax Notation 1(ASN. 1)用来组织复杂数据对象的表示法。3

5、.2公钥证书public key certificate用户的公钥连同其他信息，并由发布该证书的证书认证机构的私钥进行加密使其不可伪造。3.3证书持有者certificate holder有效证书的主体对应的实体。3.4证书用户certificate user需要确切地知道另一实体的公开密钥的某一实体。3.5证书认证机构（CA) Certificate Authority(CA)负责创建和分配证书，受用户信任的权威机构。用户可以选择该机构为其创建密钥。3.6证书认证路径certification path一个DIT中对象证书的有序序列，通过处理该有序序列及其起始对象的公钥可以获得该路径的末端对

6、象的公钥。GB/T 19714-20053.7认证业务说明（CPS) Certification Practice Statement(CPS)证书认证机构发放证书时遵循的业务说明。3.8交叉证书cross-certificate两个CA间为交叉认证所互相签发的数字证书。3.9CRL分布点CRL distribution point一个CRL目录项或其他CRL分发源；由CRL分布点分发的CRL可以包括仅对某CA所发证书全集某个子集的撤销条目，或者可以包括有多个CA的撤销条目。3. 10证书撤销列表（CRL) Certificate Revocation List(CRL)一个已标识的列表，它指

7、定了一套证书发布者认为无效的证书。除了普通CRL外，还定义了一些特殊的CRL类型用于覆盖特殊领域的CRL o3.11发证certify颁发一个证书的行为。3.12可辨别编q规1RIJ (DER) Distinguished Encoding Rules(DER)对ASN. 1对象进行编码的规则。注：本标准中使用DER对ASN. 1对象进行编码。3.13数字签名digital signature允许接收者验证签名人的身份和数据完整性的数据单元。3.14目录服务（DS) Directory Service(DS)分布在网络中的各种节点或服务器提供的分布式数据库服务。3.15终端实体end enti

8、ty不以签署证书为目的而使用其私钥的证书主体或者是依赖（证书）方。3.16散列函数hash function哈希函数将值从一个大的（可能很大）定义域映射到一个较小值域的（数学）函数。“好的”散列函数是把该函数应用到大的定义域中的若干值的（大）集合的结果可以均匀地（和随机地）被分布在该范围上。3.-17散列码Hash code散列函数的输出比特串。3. 18消息认证码(MAC) Message Authentication Code(MAC)通过密码技术由消息产生的认证数据。 GB/T 19714-20053.19消息摘要message digest散列一个消息后得到的固定长度数据。3.20个人

9、安全环境（PSE) Personal Security Environment (PSE)证书及私钥的终端实体的安全本地存储。3.21拥有证明（POP) Proof of Possession (POP)终端实体用以证明自己拥有（即能够使用）与为之申请证书的公钥相对应的私钥。3.22策略映射policy mapping当某个域中的一个CA认证另一个域中的一个CA时，在第二个域中的特定证书策略可能被第一个域中的证书认证机构认为等价（但不必在各方面均相同）于第一个域中认可的特定证书策略。3.23注册机构（RA) Registration Authority(RA)为用户办理证书申请、身份审核、证书

10、下载、证书更新、证书注销以及密钥恢复等实际业务的办事机构或业务受理点。3.24资料库repository存储证书和CRI、等信息，并提供无需验证的信息检索服务的数据库。3.25自颁发证书self-issued certificate证书的主体和颁发者相同的CA证书。4缩略语下列缩略语适用于本标准：CA证书认证机构CRI.证书撤销列表PKCS公钥密码系统PKI公钥基础设施POP拥有证明PSE个人安全环境RA注册机构TCP传输控制协议5 PKI管理概述5. 1 PKI管理模型在详细阐述特定的消息格式和流程之前，首先要定义一下PKI管理中所涉及到的实体以及它们之间的交互行为（根据PKI管理所需的功能

11、）。然后再对这些功能进行归类，以包含可以确定的不同类型的终端实体。5.2 PKI实体的定义PKI管理中所涉及到的实体包括终端实体和证书认证机构。注册机构也可以被包括在内。cB/T 19714-20055.2.1主体和终端实体终端实体是不以签署证书为目的而使用其私钥的证书主体或者是依赖（证书）方。“主体”在此处是指被授予证书的实体，一般在证书的主体或主体可替换名字段中指定。当要区分主体所使用的工具和或软件时（例如：一个本地的证书管理模块），使用术语“主体设施”。通常优先使用术语“终端实体”而不是“主体”，以防止与证书字段名中的主体相混淆。需要着重指出的是：终端实体在此处不仅包括应用软件的使用者，

12、也包括软件本身（例如IPSec的情况）。这一因素影响着PKI管理操作所使用的协议。例如，与个人用户相比，应用软件更有可能确切知道需要使用证书中的哪个扩展项。PKI管理实体也被看作为一个终端实体，因为它们有时候也在证书（或交叉证书）的主体或主体可替换名字段中被指定。如无特殊说明，术语“终端实体”将不会被用来指代PKI管理实体。所有的终端实体都需要安全可靠的访问一些本地信息，至少包括：实体自己的名字和私钥，被该实体直接信任的CA的名字及其公钥（或公钥指纹，如果可以通过其他的方式得到自签名证书）。软件实现可以使用安全本地存储机制存储上述信息，但不限于上述信息（例如：还可以包括用户自己的证书以及应用软

13、件特有的信息）。存储方式也可以不同，例如普通的文件或抗攻击的密文存储介质。像这样安全的本地存储在这里被称之为终端实体的个人安全环境。尽管有关PSE格式的内容已经超出本标准的范围（与设备及其他信息相关），但这里定义了一种通用的PSE数据交换格式认证响应消息。5.2.2证书认证机构（CA)证书认证机构是负责创建和分配证书，受用户信任的权威机构。用户可以选择该机构为其创建密钥。从终端实体的角度出发，CA可以是，也可以不是一个事实上真正的“第三方”。绝大多数情况下，CA与其所服务的终端实体属于同一个机构。同样，我们使用术语“CA”指代证书中签发者（(issuer）字段所代表的实体。当需要与CA所使用的

14、软硬件工具相区分时，我们使用术语“CA设施”。CA设施一般包括离线模块和在线模块，只有CA的离线模块可以使用CA的私钥。尽管是否这样做与CA的策略相关，但这取决于软件实现者。我们使用术语“根CA”来指代被终端实体直接信任的CA；即安全地获取根CA的公钥需要一些额外的步骤。这一术语并不意味着根CA必须处于CA体系层次的顶层，它只是说明该CA是被终端实体直接信任的。“下级CA子CA）不是终端实体的根CA。通常，下级CA不是任何实体的根CA，但这并不是强制的。5.2.3注册机构（RA)注册机构是为用户办理证书申请、身份审核、证书下载、证书更新、证书注销以及密钥恢复等实际业务的办事机构业务受理点，亦称

15、证书注册审核中心。除了终端实体和CA之外，很多应用环境要求把注册机构从证书认证机构中独立出来。(RA存在的原因参见附录Ao)RA所具有的功能将因情况不同而有所不同，可能包括个人身份鉴别、介质分发、作废报告、名称分配、密钥产生、密钥归档等等。本标准将RA作为可选的组成部分，当RA不存在时，假定CA可以实现RA的功能。从终端实体的观点看，它们都使用相同的PKI管理协议。同样，当需要区分RA和RA所使用的工具时，使用“RA设施”这个术语。应该注意到RA本身也是一个终端实体，一个被验证了的终端实体，它有自己的私钥进行数字签名和身份认证。CA设施如何把某些终端实体认定为RA则是一个实现问题（本标准不阐述

16、特定的RA认证操作）。并不强制RA必须可以被与其正通信的CA所认证（所以一个RA可以只被认证一次，与多 GB/T 19714-2005个CA协同工作）。在某种情况下，即使存在RA，终端实体可能仍然需要和CA直接通信。例如，在RA进行登记和接受审核，而直接与CA通信来更新证书。5. 3 PKI管理要求PKI管理的要求如下：a) PKI管理必须符合GB/T 16264. 8-2005及相关修订补篇（指证书扩展项）；b) PKI管理必须符合PKI系列草案的其他标准；c）必须能够在不影响其他密钥对的前提下定期地更新任意密钥对；d)为了使调整简单易行，在PKI管理协议中应尽可能少的使用加密；e) PKI

17、管理协议必须允许使用不同的工业标准加密算法。这意味着，原则上，任何给定的CA,RA或终端实体，可以使用任何适合其所拥有的密钥对的算法；f) PKI管理协议一定不能排除密钥对由相关的终端实体或RA或CA产生。密钥产生也可以在其他地方完成，出于PKI管理的目的，我们可以认为密钥生成发生在密钥第一次出现的地方：终端实体、RA或CA;g) PKI管理协议必须能够支持相关终端实体或RA,CA进行证书发布。在不同实现和不同的环境下可以采用上面任何一种方法；h) PKI管理协议必须允许通过认证的终端实体请求作废证书，以签发CRL。这一功能必须能够尽可能防止拒绝服务攻击；i) PKI管理协议必须能够使用各种不

18、同的传输机制，特别是邮件传输协议、HTTP, TCP/IP和FTP；j）签发证书的最终决定权属于CA. RA或终端实体都不能假定CA签发出来的证书符合它们的全部要求。CA可以根据其运营策略，改变一个证书字段的值，或者添加、删除、修改证书扩展项。换句话说，所有的PKI实体（终端实体、RA,CA）都必须能够处理那些与其请求不一致的证书响应（例如：CA可能会缩短证书有效期）。CA策略可能作出规定，在证书请求者检查并接受新签发的证书之前，CA机构不能发布或分发该证书（通常使用证书确认消息完成这一功能）；k) PKI管理协议必须能够支持未泄密的CA密钥对的更新（即CA密钥更新）。如果CA发生密钥泄露，那

19、么该CA所辖的全部实体都必须重新进行初始化操作。在CA密钥更新以后，PSE中包含CA新公钥的终端实体，必须仍然能够验证使用旧的CA公钥能够验证的证书。直接信任旧的CA密钥对的终端实体，也必须能够验证新的CA私钥所签发的证书；1)在某些实现或情况下，RA的功能可能会由CA来承担。PKI管理协议的设计，必须满足下面的条件：终端实体不管与CA还是与RA通信都应该使用相同的协议；m）当终端实体发出的证书请求带有公钥时，必须能够证明拥有相应的私钥。完成此项工作可以用不同方法，究竟采用哪一种取决于认证请求的类型。关于证书管理协议消息中定义的带内方法完成以上工作的详细内容见6. 3 05. 4 PKI管理操

20、作图1描述了PKI管理操作所定义的各个实体间的关系。可以沿着字母标明的线路发送PKI消息。GB/T 19714-2005一图1 PKI实体在上层，各种PKI操作可以按下列方式分组：a) CA的建立。当建立一个新的CA时，需要完成一些必要的操作（例如：发布初始CRL，导出CA公钥）。b)终端实体初始化：包括导入根CA公钥，以及获得PKI管理实体所支持的可选项信息。c)认证：各种操作都将导致创建新的证书：1)初始注册和认证：终端实体在CA为它签发证书之前第一次向CA或RA表明自己的身份。这一过程成功时的最终结果是CA为终端实体的公钥签发证书，并将该证书返回给终端实体和或将该证书发布到公共的数据仓库

21、中。这一过程通常包括多个“步骤”，还可能包括终端实体设施的初始化过程。例如，终端实体设施必须能够安全地导入CA公钥，以用来验证证书路径。此外，终端实体通常还需要导入自己的密钥对。2)密钥对更新：任何密钥对都需要定期更新（即用新的密钥对替换旧的密钥对），因此需要签发一个新的证书。3)证书更新：由于证书会过期，如果其他相关信息没有变化，那么证书就可以被“刷新”。4) CA密钥对更新：同终端实体一样，CA密钥对也需要定期更新，但需要不同的机制。 GB/T 19714-20055)交叉认证请求：一个CA请求另一个CA签发一个交叉证书。“交叉证书”的主体CA与签发者CA完全不同，主体公钥信息（Subje

22、ctPublicKeyInfo)字段包含着验证密钥（即该证书是为主体CA的签名密钥对签发的）。交叉证书细致的区分时使用下面的术语：“域间交叉证书”如果交叉证书的主体CA和签发者CA属于不同的管理域；其他的交叉证书则称作“域内交叉证书”。注1：上面所定义的“交叉证书”与X.509中定义的“CA证书”是并列的。注意不要把“交叉证书”同X. 509中的“cACertificate，属性相混淆，它们之间没有联系。注2：除非特别说明，否则一般认为术语“交叉证书”指的就是“域间交叉证书”。注3：交叉证书的签发可以是相互的（但并非必须这样做）；换句话说，两个CA可能彼此为对方签发交叉证书。6)交叉证书更新：

23、与普通证书更新类似，不同之处就在于它操作的是交叉证书。d)证书CRL搜索操作：某些PKI管理操作将导致发布证书或CRLa1)证书发布：产生证书之后，就需要通过一些方法发布这些证书。PKIX中定义的方法可以是7. 3. 13-7. 3. 16中规定的方法，或者是RFC2559, RFC2585(PKIX系列规范的“操作协议”方案）中描述的其他方法（例如：LDAP) a2) CRI，发布：与证书发布类似。e）恢复操作：当一个PKI实体“丢失”它的PSE时，需要通过某些PKI操作完成恢复工作。密钥对恢复：作为可选操作，用户密钥资料（例如用户的解密密钥）可以由CA,RA或与CA或RA相关的密钥备份系统

24、进行备份。如果一个实体需要恢复它已经备份的密钥资料（例如忘记了私钥保护密码或丢失了密钥链文件），就需要一个支持密钥恢复的协议消息。f)撤销操作：某些PKI操作将需要创建新的CRI_条目或新的CRI_撤销请求：一个经过授权的人向CA发出异常情况警告并要求撤销证书。g) PSE操作：PSE操作（例如转移PSE、更改口令等）的定义超出了本标准的范围，这里我们还是定义了一个PKI消息（CertRepMessage)，它可以作为该操作的基础。注：在线协议并非是实现以上操作的唯一途径。对任何一个操作来说，离线方法可以达到同样的效果，本标准也并不强制使用在线协议。例如：当使用硬件介质时，很多操作都通过物理介

25、质的传送来完成。后面将定义一组支持以上操作的标准消息。关于在不同环境中传送这些消息的传输协议（基于文件的、在线、E-mail和WWW）的定义，已经超出了本标准的范围，将在其他文档中单独说明。6前提与限制6.1终端实体初始化对于每一个终端实体，在与PKI管理实体进行交互之前，首先要申请获得一些信息，包括获得PKI系统所支持的功能、安全获得相关根CA的公钥。6.2初始注册认证终端实体的初始化注册和认证有很多种方案。由于CA执行的策略各不相同，并且终端实体的类型也有所不同，因此没有一种方案能适应所有的环境。初始化注册前，终端实体与PKI还没有任何的联系。当终端实体已经拥有认证过的密钥对时，就可以进行

26、简化或选择其他的方案。以下对本标准支持的初始化注册和认证方案进行分类。方案中一部分为强制性的，一部分为可选择的。强制性的方案能够覆盖到大多数的实际应用，而可选方案满足那些不是很常用的应用。这样，在系统的灵活性和系统实现的简便上进行了折衷。6.2.1所用的准则6.2.11注册认证的启动就产生的PKI消息而言，初始化注册认证的启动发生在产生第一条与终端实体相关的PKI消息GB/T 19714-2005的地点。可能的场所是在终端实体，RA或者CAo6.2.1.2终端实体消息的最初认证终端实体产生的请求证书的在线消息认证与否都可以，但要求对最初终端实体发给PKI(CA/RA)的任何消息进行认证。在本标

27、准中，PKI(CA/RA）通过带外方式向终端实体发放秘密数据（初始认证密钥）和参考数据（用于识别密钥）来完成。然后初始认证密钥就可以用来保护相关的PKI消息了。因此，通过判断在线消息是否经过初始鉴别从而对初始注册认证方案进行分类。注1：本标准不讨论对PKI系统发给终端实体的消息的认证，因为在所有情况下，在终端实体设施安装根CA的公钥或基于初始认证密钥都可以实现这一认证。注2：如果终端实体发送的消息通过带外方式被鉴别，那么可以认为初始注册认证流程是安全的。6.2.1.3密钥产生的地点在本标准中，认为“密钥产生”的地点是密钥（无论是公钥还是私钥）第一次在PKI消息中出现的地方。注意，这不排除有一个

28、密钥集中产生的服务，密钥可以在其他地方产生，然后使用一个（自定义的或者标准的）密钥产生请求响应协议（该协议不在本标准的讨论范围之内）导人到终端实体、RA或CA中。密钥产生的地点有三种可能：终端实体、RA或者CAo6.2.1.4成功认证的确认在为一个终端实体创建初始证书以后，通过让终端实体显示确认成功地接收到了包含证书（或表明证书已生成）的消息，从而可以得到附加的保证。当然，这个确认消息必须受到保护（通过初始认证密钥或者其他方式）。这又提供了两种可能性：确认的或者未确认的。6.2.2强制的方案上面的标准考虑到了大多数的初始注册认证方案。要求符合本标准的CA设施、RA设施和终端实体设施必须支持下面

29、的第二种方案。如果需要，任何实体还可以支持其他的方案。6.2.2.1集中方案按照上面的分类标准，这种方案可能是最简单的：启动发生在进行认证的CA;不要求在线消息的认证；密钥由进行认证的CA产生（见6.2.1.3);不要求确认消息。从消息流的角度来看，本方案意味着只要求一个由CA发送给终端实体的消息。这个消息必须包含终端实体的全部PSE信息。该消息使用加密传输，通过带外方式通知终端实体（如用电话通知消息的保护口令），使终端实体认证并解密接收到的消息。6.2.2.2基本认证方案按照上面的分类标准，本方案如下：启动发生在终端实体；要求进行消息认证；密钥由终端实体产生（见6. 2. l. 3) ;要求

30、确认消息。从消息流的角度来看，基本认证方案见图2 ; GB/T 19714-2005终端实体RA/CA带外方式分发初始认证密钥（IAK）和参考数据（RA/CA一、EE)产生密钥生成认证请求利用IAK保护请求一一认证请求一一验证请求处理请求生成认证响应一一认证响应一一处理响应生成确认消息一一证书确认消息一一验证确认消息生成响应一一确认ack（可选的）一一处理响应图2初始化注册认证基本方案在验证证书确认消息失败的情况下，如果新签发的证书已经发布或者可以由其他的方式获得，那么CA/RA必须撤销该证书。6.3私钥拥有证明为了使CA和RA能够有效地验证终端实体和密钥对间的绑定是否合法，这里定义一种PKI

31、管理操作，终端实体可以通过这种操作证明自己拥有并能使用与申请证书的公钥相对应的私钥。一个CA/RA在认证交换时可以自由选择如何实现POP例如带外方式或带内方式）。目前有很多非PKIX的操作协议（例如各种电子邮件协议），并不明确验证终端实体和私钥间的绑定；因此要求CA/RA必须通过某种方式实现POP。在验证绑定（签名、加密和密钥协商密钥对）的操作协议广泛存在之前，绑定的验证只能被RA/CA实现。因此，没有被RA/CA验证绑定的PKI证书就会因为没有任何意义而终止。按照证书申请中的密钥对类型的不同，POP须通过不同的方式完成。如果是一个多种用途的密钥，那么，任意一种适当的方法都可以使用（例如，如果

32、一个密钥可以用于签名以及其他应用，那么就不能将它送到CA/RA去验证POP) o本标准允许终端实体向RA提供相关证明，随后RA向CA说明需要的证明已经完成（并验证）。例如：一个想要申请签名证书的终端实体向RA送去签名信息，RA随后通知CA终端实体已经提供了要求的证明。当然，某些策略可能不允许这种情形（例如，CA可能是认证过程中唯一可以验证POP的实体）。6.3.1签名密钥对于签名密钥的情况，终端实体通过对一个数据签名来证明拥有私钥。6.3.2加密密钥对于加密密钥的情况，终端实体可以将私钥提供给CA/RA，或者通过解密一段数据来证明对私钥的拥有（见7.2.8)。解密数据可以是直接方式也可以是间接

33、方式。直接方式是RA/CA给终端实体发送一个随机的挑战数，同时要求终端实体立即返回响应。间接方式是给终端实体返回加密的证书（让终端实体在确认消息中证明它能解开这个证书）。这使得只有预期的终端实体才能使用CA签发的证书。本标准鼓励使用间接方式，因为这种方式不需要发送额外的消息（即可以使用消息三元组请求，响应，确认来证明）。GBJT 19714-20056.3.3协商密钥对于协商密钥的情况，为了证明终端实体拥有私钥，终端实体和PKI实体（RA或者CA）必须建立一个共享的密钥。注意，这种方法并不需要对CA可以认证的密钥做什么限制对于Diffie-Hellman密钥，终端实体可以自由选择它的算法参数只

34、要CA在需要时可以利用适当的参数生成短期（或一次性）的密钥。6.4根CA的更新这里只描述对某些终端实体来说是根CA的情况。这里所描述流程的基础是CA利用旧私钥保护新私钥同时利用新私钥保护旧私钥。因此，当CA更新密钥对时，如果证书要在X. 500目录服务器发布，则必须生成两个额外的cACertificate属性值（这样共有四个：oldWithOld,oldWithNew,newWithOld以及newWithNew) o当一个CA更改密钥对的时候，那些已经通过带外方式持有该CA旧公钥的终端实体受到的影响最大。这些终端实体需要访问由旧私钥保护的CA新公钥。然而，它们只在一个有限的时间段需要这一证书

35、（直到它们通过带外方式获得新的CA公钥）。通常，当这些终端实体的证书到期的时候，这自然便实现了。用来保护新旧CA公钥的数据结构不是新的数据结构，是标准的证书结构（也可能包含扩展项）。注I：为了支持VI版本证书，目前的方案没有利用任何X. 5090的证书扩展项。密钥标识（KeyIdentifier）扩展项的存在是为了提高效率。注2：可以将这一方案进行推广，以适应CA在它的任一终端实体证书的有效期内多次更新自己密钥对的情形，但这种推广似乎没有什么价值。不作这种推广仅仅意味着CA密钥对的有效期必须比用这对密钥签发的所有证书的有效期都长。注3：本方案确保终端实体最晚将在它所拥有的由CA旧公钥签发的最后

36、一个证书过期时获得CA新公钥（通过带外方法）。发生在其他时候的证书和或密钥更新操作并不要求这一点（这依赖于终端实体设施）。6. 4. 1 CA操作员的行为要更新CA的密钥，CA操作员要完成以下操作：a)产生新密钥对；b）产生一个用新私钥为旧公钥签名的证书（old with new，证书）；c）产生一个用旧私钥为新公钥签名的证书（new with old，证书）；d）产生一个用新私钥为新公钥签名的证书（new with new，证书）；e）通过数据仓库或其他方式发布这些新证书（可能使用CAKeyUpdAnn消息）；f)导出CA新公钥，这样终端实体就可以通过带外方式获得（如果需要的话）。旧CA私钥

37、将不再使用。但旧CA公钥还会延续使用一段时间。当CA所属的终端实体都已经安全地获得了CA新公钥的时候，旧公钥就不再使用了（防抵赖除外）。old with new”证书的有效期必须从旧密钥生成的时间开始，到旧公钥到期的时候结束。new with old”证书的有效期必须从新密钥对生成的时间开始，到足以保证所有终端实体都得到了新的CA公钥时结束（最晚到旧公钥到期的时候）。new with new”证书的有效期必须从新密钥对生成的时间开始，到CA下一次更新其密钥时或CA下一次更新其密钥之前结束。6.4.2验证证书通常在验证签名的时候，验证者要验证包含签名者公钥的证书。然而，一旦允许CA更新密钥，就会

38、出现很多新的可能性，如表1所示： GB/T 19714-2005表1验证签名可能情况一一习6.4.2.1在情况1、情况4、情况5和情况8下的验证在这样的情况下，验证者拥有CA公钥的一份本地拷贝，可以用来直接验证证书。这种情况与没有密钥更新时是一样的。第8种情况会在CA操作员已经生成了新密钥和将新密钥导人系统之间的时候出现。当此间隙期间CA操作员已经发布了签名者和验证者的证书的时候，情况5会出现（CA操作员要尽量避开这样的情况）。6.4.2.2在情况2下的验证在情况2下，验证者必须得到CA的旧公钥。验证者执行下列操作：a）在数据仓库中查找caCertificate属性，获得OldWithNew证

39、书（基于有效期来判断，注意主体和签发者字段必须匹配）；b)利用CA新密钥（验证者本地拥有的）验证该证书是否正确；。）如果正确，利用CA旧密钥验证签名者的证书。当CA操作员先为签名者签发了证书，更新CA密钥后，又为验证者签发证书时，会发生这种情况，因此这是一种很典型的情况。6.4.2.3在情况3的验证在第3种情况下，验证者必须要取得CA的新公钥，验证者执行下列操作：a）在数据仓库中查找caCertificate属性，获得NewWithOld证书（基于有效期来判断，注意主体和签发者字段必须匹配）；b)利用CA旧密钥（验证者本地拥有的）验证该证书是否正确；c）如果正确，利用CA新密钥验证签名者的证书

40、。当CA操作员先为验证者签发了证书，更新CA密钥后，又为签名者签发证书时，会发生这种情况，因此这也是一种很典型的情况。6.4.2.4在情况6下的验证失败在这种情况下CA已经为验证者签发了包含新密钥的PSE但尚未更新数据仓库中的属性。这意味着验证者无法得到可信赖的CA的旧密钥，所以验证失败。此失败是由CA操作员的错误造成的。6.4.2.5在情况7下的验证失败在这种情况下，CA已经用新密钥为签名者签发了证书但尚未更新数据仓库中的属性。这意味着验证者无法得到可信赖的CA旧密钥，所以验证失败。此失败也是由CA操作员的错误造成的。6.4.3作废CA密钥的改变如上所述，一旦允许更改CA密钥，那么证书的验证

41、将变得更为复杂。对于作废检查也存在同样的GB/T 19714-2005问题，因为CA可能利用新私钥而不是用户PSE中已经存在的私钥签发CRL o对各种情形的分析与证书验证相同。7数据结构7. 1 PKI消息综述本标准中所有用于PKI管理的消息都采用下面的结构：PKIMessage：SEQUENCEheader PKIHeader,body PKIBody，protection 0 PKIProtection OPTIONAL,extraCerts仁1 SEQUENCE SIZE（I二MAX) OF Certificate OPTIONALPKIMessages：SEQUENCE SIZE（1.

42、。MAX) OF PKIMessagePKIHeader包含许多PKI消息公有的信息。PKIBody包含与具体消息相关的信息。PKIProtection字段是可选的，包含对PKI消息进行保护的比特串。extraCert，字段可以包含对接收者来说可能有用的证书。例如，CA或RA可以利用这一字段向终端实体提供它验证自己的新证书时所需要的证书（例如，如果签发终端实体证书的CA对它来说不是一个根CA)。注意，这个字段不一定包含一个证书链为了使用证书，接收者可能需要对这些证书进行分类、选择或其他处理。7. 1. 1 PKI消息头所有的PKI消息都要求使用消息头的某些信息进行寻址和交易标识。某些同样信息也

43、出现在与传输相关的信封中。不管采用哪种方法，只要PKI消息受到保护，这些信息就会同样受到保护。下面的数据结构用于保存这些信息：PKIHeader：SEQUENCEpvno INTEGERcmp1999（1），cmp2000 (2)，sender GeneralName，一标识发送者recipient GeneralName，一标识预期的接收者messageTime 0 GenerahzedTime OPTIONAL,一产生这个消息的时间（当发送者认为该时间的传输合适时使用一即接收方接收到消息时这个时间仍有意义）protectionAlg 1 AlgorithmIdentifier OPTION

44、AL,一用于计算protection比特的算法senderKID 2 KeyIdentifier OPTIONAL,recipKID 3 KeyIdentifier OPTIONAL,一标识用于保护的特定密钥transactionlD 4 OCTET STRING OPTIONAL,一标识交易；即在相关的请求、响应和确认消息中，该字段值相同senderNonce 5 OCTET STRING OPTIONAL,recipNonce 6 OCTET STRING OPTIONAL,一用于防止重放攻击的随机数，senderNonce由消息的创建者赋值 GB/T 19714-2005一recipNo

45、nce是由本消息的预期接收者先前插人到相关消息中的随机数freeText 7 PKIFreeText OPTIONAL，一可以用于表示上下文相关的说明（本字段主要由人工使用）generallnfo 8 SEQUENCE SIZE（1.。MAX) OFInfoTypeAndValue OPTIONAL一可以用于表示上下文相关的说明（本字段不是供人工使用的）PKIFreeText：SEQUENCE SIZE（1二MAX) OF UTF8String一按UTF-8RFC2279编码的文本（注意：每一个UTF8String都可以包含一个RFC 1766/RFC 3066语言标签，用于表示所包含文本属于

46、哪一种语言）一详情请参见RFC2482对于该版本pvno字段取固定值2asender字段包含PKIMessage发送者的名字。这个名字（与senderKID一起，如果提供的话）应当能够标识出对这一消息的保护进行验证所需要的密钥。如果发送方实体并不清楚自己的任何信息（例如：在初始化请求消息中，终端实体并不清楚自己的DN、电子邮件、IP地址等），那么“sender”字段必须包含一个“NULL”值；即一个长度为0的SEQUENCE OF。在这种情况下，senderKID字段必须包含一个标识符（即一个参考数），这个标识符能够向接收者表明验证消息所用的共享密钥信息。recipient字段包含PKIMessage接收者的名字。这个名字（与recipKID一起，如果提供的话）应当可以用于验证对消息的保护。protectionAlg字段指明保护消息所用的算法。如果没有提供保护比特位（注意PKIProtection是可选的），那么必须省略这个字段；如果提供了比特位，那么必须提供这个字段。senderKID和recipKI