GBT19771
2023-04-21
来源：步旅网
ＩＣＳ ３５．１００．７０一一Ｌ ７９苟日中华人民共和国国家标准ＧＢ／Ｔ １９７７１－２００５信息技术安全技术公钥基础设施 ＰＫＩ组件最小互操作规范 ｏｎ Ｉｎｆｏｒｍａｔｉｔｅｃｈｎｏｌｏｇｙ－Ｓｅｃｕｒｉｔｙ ｔｅｃｈｎｏｌｏｇｙ－Ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ一Ｍｉ ｎｉｍｕｍ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｆｏｒ ＰＫＩ ｃｏｍｐｏｎｅｎｔｓ２００５－０５－２５发布２００５－１２－０１实施丰 督锲臀策蟾臀袋臀臀暴发“ＧＢ／Ｔ １９７７１－２００５ｍｌ １青 本标准是在参考美国国家标准与技术研究院（ＮＩＳＴ）提出的《公钥基础设施ＰＫＩ组件最小互操作规范》第二版内容的基础上修改而成，同时本标准还参照了包括证书管理策略（ＣＭＰ ）、证书请求消息格式（ＣＲＭＦ）， ＦＩＰＳ许可的密码算法和Ｘ９密码算法等相关的规范。 本标准凡涉及密码算法相关内容，按国家有关法规实施。本标准中引用的ＳＨＡ－１，ＲＳＡ，ＳＨＡ１－ＭＡＣ，ＳＨＡＩ－ＨＭＡＣ ，ＤＥＳ－ＭＡＣ，ｔＤＥＡ密码算法均为举例性说明，具体使用时均须采用国家商用密码管理委员会批准的相应算法。 本标准的附录Ａ、附录Ｂ、附录Ｃ、附录Ｄ为规范性附录。本标准由中华人民共和国信息产业部提出。 本标准由全国信息安全标准化技术委员会（ＴＣ２６０ ）归口。 本标准起草单位：信息安全国家重点实验室、中国电子技术标准化研究所。本标准主要起草人：冯登国、吴志刚、荆继武、高能、向继、张凯、周瑞辉、徐佳、林爆锵、曹政、 余蜻、廖洪蛮、李丹、罗锋盈、陈星。ＧＢ／Ｔ １９７７１－２００５引 言数字签名证书在政府服务商业和法律程序中代替手写签名，并且允许以前没有联系的双方可靠地 鉴别对方以进行商业事务。加密证书提供了加密传输和加密算法的应用，来建立或保护对称密钥以提供机密性。这样的一个公钥基础设施（ＰＫＩ ）系统和它相应的证书，也许远远超出了一些应用的实际需要，对那些特别的应用要求来说改进的证书和协议更合适。ＧＢ／Ｔ １９７７１－２００５信息技术安全技术公钥基础设施 ＰＫＩ组件最小互操作规范 １范围本标准支持大规模公钥基础设施（ＰＫＩ负责发布、撤销和管理用于数字签名及密钥管理的公钥证 书）的互操作性。本标准为不同的ＰＫＩ开发者所开发的组件产品提供了基本的互操作性参考。本标准的内容涉及： 公钥证书的产生、更新和撤销；签名的产生和验证； 证书和证书认证路径验证。 本标准主要包括了对证书、证书撤销列表（ＣＲＩ．）扩展和一套事务的描述。这些事务包括证书申请、证书更新、证书撤销以及从资料库检索证书和ＣＲＬａ本标准主要以最终用户的角度来看待ＰＫＩ的互操作性，即怎样申请和获得一个证书；怎样签署文 档；怎样检索他人的证书；怎样验证签名。就像下面所提及的，ＰＫＩ的“内部”操作规范还没有达到足够成熟，因此它们没有被详细规定。在本标准中ＰＫＩ被分成五个组件： 颁发和撤销证书的证书认证机构（ＣＡｓ）；确保公钥和证书持有者的身份以及别的属性之间绑定的注册机构（ＲＡｓ ） ；获得证书和签署文档的证书持有者； 验证签名并且执行密钥管理协议以及验证证书认证路径的客户； 存储并提供对证书和ＣＲＬ查询的资料库。许多实体在功能上既是证书持有者又是客户。ＣＡｓ和ＲＡｓ也是如此。终端实体证书持有者通常 也是客户。当然，也有一些客户并不是证书持有者。资料库不必是证书持有者和客户。本标准仅仅涉及资料库协议的一部分，那就是客户要求从资料 库中获得证书和ＣＲＩ．的信息。本标准将轻型目录访问协议（ＬＤＡＰ）版本２作为用户访问资料库的传输手段，因为它是被广泛接 受和采用的方法。例如，这种选择既不强调ＣＡ用来更新资料库的标准化协议，也不强调资料库之间互相映射的协议，尽管它们都是需要的。前者可以具体情况具体分析以解决ＣＡ和资料库之间的协议，后者也许并不必要。在通常的证书状态确认（本标准遵循的）中，资料库不是可信实体，ＣＡ对ＣＲＬ的签名更可靠。在 线证书状态实时确认机制要求资料库是可信实体，而且它们也能让客户相信他们的身份。这样的证书状态确认协议超出了本标准的范围，但是在一些应用中可能需要实时证书状态确认，所以在以后的修订版中可能会解决这个问题。本标准中没有提供让资料库验证使用者的协议， 该协议是资料库记费应用的前提。虽然这可能是资料库重要的商用模式，但目前人们对该模式的看法还没有达到一致，也没有统一的支撑协议。在以后的修订版中可能会解决这个问题。在一些情况下，带外事务也是本标准中事务的一部分。带外事务的形式和内容超出了本标准的 范围。本标准假定ＣＡ，ＲＡ和证书持有者是物理＿ Ｌ分离的。如果这些实体在物理上是在一起的话，那么ＧＢ／Ｔ １９７７１－２００５对特定接口的支持是不需要的。具体地说，如果一个ＰＫＩ组件既包含ＲＡ又包含ＣＡ的功能，那么就不必支持这两者之间的事务消息格式。然而，如果一个系统包括一个ＣＡ，该ＣＡ除了具有本地ＲＡ功能以外还支持远程ＲＡ，那么它就必须支持和远程ＲＡ之间的事务。在以下的论述中，我们假设ＣＡ和ＲＡ是单独的ＰＫＩ组件。 本标准把ＣＡ和ＲＡ当作ＰＫＩ系统的功能实体。这些实体的内部设计超出了本标准的范围。本标准假设， 从最小范围来讲，证书持有者有一个签名密钥和证书。可选的，证书持有者还可以获得一个加密密钥和证书。一旦证书持有者希望请求或者撤销加密证书，它就需要用签名密钥来向ＣＡ证明自己。对那些没有签名密钥对、 不需要不可否认性服务的系统，本标准不予直接支持。当然，这些实体主要是这样一些计算机系统（例如，路由器或是链路加密机），它们由管理员来维护。如果管理员有系统管理的签名密钥对，本标准的事务集合也可用来支持这些实体的证书请求和撤销。本标准选定了一个成熟重要的数字签名算法，新的标准算法很容易加人进来。 本标准支持层状和网状信任模型。在层次模型中，ＣＡ通过认证一个次级ＣＡ来提供可信性。信任授权从根ＣＡ开始，该ＣＡ被所有节点信任。在网状模型中，信任是建立在两个同等关系的ＣＡ中的（即交叉认证），因此两个ＣＡ之间可以有多个信任路径。最小互操作规范假设ＧＢ／Ｔ １６２６４． ８－２００５证书的扩展ｂａｓｉｃＣｏｎｓｔｒａｉｎｔｓ， ｎａｍｅＣｏｎｓｔｒａｉｎｔｓ， ｋｅｙＵｓａｇｅ和ｃｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｙ都会包含在证书中，以便对信任关系进行明确管理。本标准假设无需确认就可以从资料库中检索证书和ＣＲＩ，。客户可以从适当的资料库中获得证书 和ＣＲＬ来进行路径验证。资料库可以是Ｘ． ５００目录或者使用通用资源标识符（ＵＲＩ）可访问的目录。希望资料库能够支持ＬＤＡＰ（即ＲＦＣ １７７７），因此相应的产品也要求支持这个协议。资料库不必连接在一起，别的协议也可以用来获得证书和ＣＲＩ，。本标准要求明确所使用的证书资 料库和检索证书以及ＣＲＩ，的机制。 ＣＲＬ是一个广泛使用的机制，它用于撤销证书和验证未到期证书的状态。ＣＲＬ的使用可能还没有统一。一些ＣＡ选择在线实时确认证书状态的机制，ＣＲＩ，的产生对于别的ＣＡ的使用者来说应该具有互操作性。除了当前检查证书的有效性，ＣＲＩ，还提供了一个重要的机制，即将证书以前的撤销状态存档。如果一个带日期签名的签名日期在证书的有效期内，那么该签名是合法的，当前的ＣＲＩ，不会显示证书被撤销的信息。在本标准中， 假设ＣＡ可以产生ＣＲＩ．，客户在验证证书时可以使用ＣＲＬ．２规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有 的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。ＧＢ／Ｔ １６２６４． ８－２００５信息技术ＩＥＣ ９５９４－８：２００１，ＩＤＴ）开放系统互连目录第８部分：公钥和属性证书框架（（ＩＳ（）／ ＩＳＯ／ＩＥＣ ８８２５－１：２００２信息技术ＡＳＮ． １编码规则规则（ＣＥＲ）和非典型编码规则（ＤＥＲ）规范第１部分：基本编码规则（ＢＥＲ ）、正则编码 ＡＮＳＩ Ｘ９．５２用于金融服务业的公钥密码算法：三重ＤＥＳ操作模式ＡＮＳＩ Ｘ９．５５用于金融服务业的公钥密码算法：公钥证书扩展和证书撤销列表扩展ＲＦＣ ８２２ Ｉｎｔｅｒｎｅｔ文本邮件的标准消息格式ＲＦＣ １７６６语言标识用标签 ＲＦＣ １７７７轻量级目录访问协议ＲＦＣ １９５９ ＬＤＡＰＵＲＩ，格式ＧＢ／Ｔ １９７７１－２００５ ＲＦＣ ２１０４用于消息认证的带密钥散列函数ＲＦＣ ２２０２ ＨＭＡＣ－ＭＤ５和ＨＭＡＣ－ＳＨＡ－１测试用例ＲＦＣ ２３１３ ＰＫＣＳ ＃ １ ＲＳＡ加密版本１．５ ＲＦＣ ２３１４ ＰＫＣＳ ＃ １０认证请求语法版本１．５ＲＦＣ ２４５９因特网Ｘ． ５０９公开密钥基础设施证书和证书撤销列表框架 ＲＦＣ ２５１０因特网Ｘ． ５０９公开密钥基础设施证书管理协议ＲＦＣ ２５１１因特网Ｘ． ５０９公开密钥基础设施证书消息格式 ＲＦＣ ２５５９因特网Ｘ． ５０９公开密钥基础设施操作协议一轻量目录访问协议版本２ＲＦＣ ２９８５ ＰＫＣＳ ＃ ９可选的对象类和参数类型版本２．０ＦＩ ＰＳ－１１３：１９８５计算机数据加密鉴别ＰＫＣＳ ＃ｎ３术语和定义下列术语和定义适用于本标准。 ３．１密码令牌接口标准版本２．０抽象语法记法一（ ＡＳＮ． １） Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ Ｎｏｔａｔｉｏｎ １（ＡＳＮ． １）用来组织复杂数据对象的表示法。 ３．２许可ａｃｃｒｅｄｉ ｔ认可一个实体或个人去执行特定动作。 ３．３公钥证书ｐｕｂｌ ｉｃ ｋｅｙ ｃｅｒｔｉｆｉｃａｔｅ用户的公钥连同其他信息，并由发布该证书的证书认证机构的私钥进行加密使其不可伪造。 ３．４ 证书持有者ｃｅｒｔｉｆｉｃａｔｅ ｈｏｌｄｅｒ有效证书的主体对应的实体。 ３．５证书策略ｃ ｅｒｔｉｆｉｃａｔｅ ｐｏｌｉｃｙ 命名的一组规则，指出证书对具有公共安全要求的特定团体和／或应用的适用范围。例如，一个特定的证书策略表明，用于确认电子数据交换贸易证书的适用范围是价格在某一预定范围内的交易。３．６ ｃｅｒｔｉ证书用户ｆｉｃａｔｅ ｕｓｅｒ需要确切地知道另一实体的公开密钥的某一实体。 ３．７证书使用系统ｃ ｅｒｔｉｆｉｃａｔｅ－ｕｓｉｎｇ ｓｙｓｔｅｍ证书用户使用的、本标准定义的那些功能实现。 ３．８证书认证机构（ ＣＡ） Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ（ＣＡ）负责创建和分配证书，受用户信任的权威机构。用户可以选择该机构为其创建密钥。 ３．９证书认证路径ｃ ｅｒｔｉｆｉｃａｔｉｏｎ ｐａｔｈ一个ＤＩ Ｔ中对象证书的有序序列，通过处理该有序序列及其起始对象的公钥可以获得该路径的末端对象的公钥。ＧＢ／Ｔ １９７７１－２００５３．１０认证业务说明（ＣＰＳ） Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｐｒａｃｔｉｃｅ Ｓｔａｔｅｍｅｎｔ（ＣＰＳ）证书认证机构发放证书时遵循的业务说明。 ３．１１ＣＲＬ分布点 ＣＲＬ ｄｉｓｔｒｉｂｕｔｉｏｎ ｐｏｉｎｔ一个ＣＲ工团目录项或其他ＣＲＩ ．分发源；由ＣＲＩ，分布点分发的ＣＲＬ可以包括仅对某ＣＡ所发证书全集某个子集的撤销条目，或者可以包括有多个ＣＡ的撤销条目。３． １２证书撤销列表（ＣＲＬ） Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ（ＣＲＬ） 一个已标识的列表，它指定了一套证书发布者认为无效的证书。除了普通ＣＲＩ，外，还定义了一些特殊的ＣＲＬ类型用于覆盖特殊领域的ＣＲＩ．３．１３发证ｃｅｒｔ ｉｆｙ颁发一个证书的行为。 ３．１４客户ｃ ｌｉｅｎｔ使用ＰＫＩ来获得证书并且去验证证书和签名的功能。 ３． １５增量ＣＲＬ ｄｅｌｔａ－ＣＲＬ部分撤销列表，在可参考的基础ＣＲＩ ，发布以后，这些证书更改了其撤销状态。３．１６可辨别编码规则（ ＤＥＲ） Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｅｎｃｏｄｉｎｇ Ｒｕｌｅｓ（ＤＥＲ）对ＡＳＮ． １对象进行编码的规则。注：本标准中使用ＤＥＲ对ＡＳＮ． １对象进行编码３．１７数字签名ｄｉ ｇｉｔａｌ ｓｉｇｎａｔｕｒｅ允许接收者验证签名人的身份和数据完整性的数据单元。 ３．１８目录服务（ＤＳ） Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ（ＤＳ）分布在网络中的各种节点或服务器提供的分布式数据库服务。 ３．１９终端实体ｅｎｄ ｅｎｔｉｔｙ不以签署证书为目的而使用其私钥的证书主体或者是依赖（证书）方。 ３．２０散列函数， 哈希函数ｈａｓｈ ｆｕｎｃｔｉｏｎ 将值从一个大的（可能很大）定义域映射到一个较小值域的（数学）函数。“好的”散列函数是把该函数应用到大的定义域中的若干值的（大）集合的结果可以均匀地（和随机地）被分布在该范围上。３．２１散列码ｈａ ｓｈ ｃｏｄｅ散列函数的输出比特串。 ３．２２ 消息认证码（ＭＡＣ） Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ（ＭＡＣ）通过密码技术由消息产生的认证数据。 ＧＢ／Ｔ １９７７１－２００５３．２３消息摘要ｍｅ ｓｓａｇｅ ｄｉｇｅｓｔ散列一个消息后得到的固定长度数据。 ３．２４带外事务ｏｕｔ ｏｆ ｂａｎｄ不是通过电子形式，而是通过通常的物理形式进行的一些ＰＫＩ组件的事务。 ３．２５策略映射ｐｏｌ ｉｃｙ ｍａｐｐｉｎｇ当某个域中的一个ＣＡ认证另一个域中的一个ＣＡ时，在第二个域中的特定证书策略可能被第一 个域中的证书认证机构认为等价（但不必在各方面均相同）于第一个域中认可的特定证书策略。３．２６注册机构（ＲＡ） Ｒｅｇｉｓｔｒａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ（ＲＡ） 为用户办理证书申请、身份审核、证书下载、证书更新、证书注销以及密钥恢复等实际业务的办事机构或业务受理点。３．２７资料库ｒ ｅｐｏｓｉｔｏｒｙ存储证书和ＣＲＬ等信息，并提供无需验证的信息检索服务的数据库。 ３．２８自颁发证书ｓ ｅｌｆ－ｉｓｓｕｅｄ ｃｅｒｔｉｆｉｃａｔｅ证书的主体和颁发者相同的ＣＡ证书。 ３．２９统一资源标识符（ＵＲＩ） Ｕｎｉ ｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）包含了名字或地址的短数据串，指向ｗｅｂ上的某个对象。 ３．３０统一资源定位符（ＵＲＬ） Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）包含地址的短数据串，指向ｗｅｂ上的某个对象，ＵＲＩ是ＵＲＩ的子集。 ４缩略语 下列缩略语适用于本标准。ＣＡ证书认证机构 ＣＲＩ，证书撤销列表 ＰＫＣＳ公钥密码系统 ＰＫＩ公钥基础设施 ＰＯＰ拥有证明ＲＡ注册机构 ５ ＰＫＩ组件规范５．１概述 本章规定了ＰＫＩ各组件进行互操作时所需的功能和事务的最小集合。它们分别是ＣＡ， ＲＡ、证书持有者和ＰＫＩ客户的规范。５．２证书认证机构（ＣＡ）５．２．１概述ＣＡ负责生成、撤销、公布和存档证书。资料库使得所有证书使用者都可以获得证书和ＣＲＩ ＿ｓ的ＧＢ／Ｔ １９７７１－２００５信息。ＣＡ生成自己的公私钥对并公布自己的证书。因此，ＣＡ应当生成、估定相应的参数以便生成／验证 它们的签名。为了使新的ＣＡ能加人到已有的层次结构中，它们应当可以从父ＣＡ那里申请证书。ＣＡ也应可以生成交叉证书，在其他ＣＡ的策略允许下支持与其他ＣＡ进行交叉认证。ＣＡ对所有的事务进行存档，这些事务包括ＰＫＩ各组件之间的服务请求与响应。ＣＡ授权ＲＡ去确认那些申请证书的使用者的身份或其他的特征属性。这种授权通过离线接受来 自某个ＲＡ的证书请求完成。ＣＡ利用Ｘ． ５００的可辨别名（ＤＮ）来唯一标识证书持有者。ＣＡ本身也具备证书持有者的功能：请求、撤销、更新由其他ＣＡ颁发的证书（５．４）；检索证书和 ＣＲＬｓ，验证证书认证路径的客户功能（５．５）０５．２．２与互操作性有关的ＣＡ功能要求ＣＡ执行下列功能： 颁发并传送证书给终端实体和其他的ＣＡ；接收来自ＲＡ的证书撤销请求； 将证书和ＣＲＬ存人资料库； 请求ＣＡ证书。ａ）颁发数字签名证书 ＣＡ支持三种有关数字签名证书的证书请求： ＲＡ发起的注册请求、更新和自我注册请求。根 据每种请求的不同，ＣＡ以不同的方式来鉴别这些申请证书主体的身份。潜在的证书持有者在自我注册请求中提供一个证据证明自己的身份已经得到了ＲＡ的核实，该证据是由从ＲＡ 那里获得的秘密信息导出的。当用户与ＲＡ物理上在一起时，ＲＡ产生并签署基于ＲＡ的登 记请求来保证该用户的身份。在证书更新请求中，当前有效证书的主体可以用它们的私钥签 名来保证它们身份的真实性。ＲＡ发起的证书请求： ＲＡ保证该用户的身份并将其和公钥绑定在一起。当ＣＡ接收到来自授权ＲＡ的证书请求时， ＣＡ就处理该请求，如果接受，就生成新证书，并将其放到资料库中，然 后将证书发给相应的ＲＡ， ＣＡ也可以直接把新证书发给该证书的持有者。如果基于ＲＡ的证书请求不是来自一个授权的ＲＡ，即签名无效， 或者包含不匹配信息，ＣＡ将会拒绝该证书请 求。如果ＣＡ拒绝了该证书请求，它将会向ＲＡ报告失败并说明原因。在自我注册证书请求中，ＲＡ为潜在证书持有者提供了一个秘密信息。请求实体产生自己的 公私钥对，组成一个证书请求消息，并用相应的私钥签名，被签名部分包括基于ＲＡ提供的秘密导出的认证信息。ＣＡ接收来自实体的证书请求，通过认证信息验证请求者的身份并且验 证实体拥有相应的私钥。如果接受，ＣＡ就产生新证书，并将其放到资料库中，然后将证书发给证书持有者。如果认证信息验证不通过，签名无效，或者包含不匹配信息，ＣＡ将会拒绝该 证书请求。如果ＣＡ拒绝了自我注册证书请求， 它将会向申请者报告失败并说明原因。证书更新请求：申请者已确定的身份通过该更新请求消息来验证。证书持有者产生更新请求 并直接发给ＣＡ， ＣＡ处理证书更新请求，如果正确的话，就把新证书发给证书持有者，并将其 放入资料库。如果签名是无效的，或者请求实体当前是非法的，或者ＣＡ认证业务说明或证书策略不允许更新请求，ＣＡ将会拒绝该证书更新请求。如果ＣＡ拒绝了更新请求，它将会向请 求实体报告失败并说明原因。ｂ）颁发加密证书 ＣＡ可以支持某个请求者发出的加密证书的证书请求， 该请求者拥有该ＣＡ颁发的有效签名 证书。请求者的身份由对请求的数字签名来验证。本标准中规定请求者的密钥对由第三方集中产生并通过带外方式提供给ＣＡ｝ 在集中密钥管理证书请求中，证书持有者生成一个证书请求，说明自己想要的加密算法，并用 ＧＢ／Ｔ １９７７１－２００５ 当前得到该ＣＡ认可的签名密钥来对该请求签名。ＣＡ响应该请求，发还一个证书和加密私钥。 ｃ）交叉认证 在一定的约束条件下ＣＡ可向别的ＣＡ颁发证书。交叉认证的决定是在带外做出的，并且要通过认证业务说明和证书策略检查。每个ＣＡ都会对它们的使用者的路径验证做出适当的约 束。在获得别的ＣＡ的公钥后， 该ＣＡ生成证书并将其存放到资料库中。可选的， 交叉认证的ＣＡ之间可以交换证书，构造证书对并把它们放人资料库。 ｄ）撤销证书ＣＡ产生和发布证书撤销列表（ＣＲＬｓ） ｏ ＣＲＬ中包括所有被撤销但没有到期的证书。可选的，ＣＡ也可以颁发间接的和增量ＣＲＬ。被颁发ＣＲＬ的形式由ＣＡ的认证业务说明决定。 在ＣＡ为所有的撤销证书仅颁布唯一的ＣＲＩ，的情况下： １）新的ＣＲＩ ，产生时，老ＣＲＩ，中的全部信息将放到它的里面，那些新被撤销的证书将被加人 到新的ＣＲＩ，。老ＣＲＬ中带ｃｅｒｔｉｆｉｃａｔｅＨｏｌｄ原因代码的证书也将被放人新的ＣＲＬ，继续保持同样的原因代码，变成一个不同的原因代码，或是被新ＣＲＬ忽略。如果被忽略就表明 ＣＡ将保证证书主体和公钥之间的绑定。那种决定撤销但还没有被撤销的证书将放人新 的ＣＲＩ ，，既使在新ＣＲＩ，发布之前它已经到期了。２）在这种情况下， ＣＡ只撤销它们自己颁发的证书。（撤销可能来自一个签名请求，或是ＣＡ 自己决定撤销。本标准中不考虑ＣＡ自己撤销证书的情况）撤销请求的签署者或者是证书持有者，或者是代表证书持有者或证书持有者组织的权威实体（比如被授权的ＲＡ），在把 证书放人ＣＲＩ，之前，ＣＡ要确认验证撤销请求。撤销请求的合法性包括请求签名的合法性。对ＲＡ签名的撤销请求进行带外验证，根据证书策略是可选的。 ＣＡ发布Ｘ． ５０９版本２的ＣＲＩ，（版本２的ＣＲＬ对应版本３的证书）。字段和扩展，以及赋给它们的值，要与６． ３． ２一致。产生和签署了ＣＲＩ，之后，ＣＡ要把它放到资料库中去。 ｅ）颁发证书、交叉证书和ＣＲＩＣＡ应当能够颁发证书，交叉证书对和ＣＲＩ ，以供ＰＫＩ ｃｌｉｅｎｔ检索。ＣＡ也应能颁发ＣＡ证书、交叉证书对、ＣＲＩ ，和终端实体的加密证书。终端实体数字签名证书的颁发是可选的。用于更 新目录的机制超出本标准范围。ｆ）请求ＣＡ证书 ＣＡ应能向层次更高的ＣＡ申请证书，以支持ＰＫＩ的层次信任模型。这个请求可以参考６． ６． ２中的描述。这个证书请求将通过６．２．３．４中描述的ｂａｓ ｉｃＣｏｎｓｔｒａｉｎｔｓ扩展来把该请求ＣＡ确定为一个实体。 ５．２．３电子事务集合提供证书管理服务所需的电子事务如下： 处理终端实体的证书请求和证书撤销请求；将证书和ＣＲＩ ．放人资料库；为了验证签名的有效性从资料库中检索证书和ＣＲＩ ． ＣＡ处理在ＣｅｒｔＲｅｑ消息中的ＲＡ发起的注册请求。ＣｅｒｔＲｅｑ消息由ＲＡ在ＰＫＩＰｒｏｔｅｃｔｉｏｎ结构里签名。通过签署请求消息，ＲＡ保证证书持有者的身份并且确认它拥有相应私钥。ＣＡ以ＣｅｒｔＲｅｐ消息回复ＲＡ或者证书持有者。如果接受请求，ＣｅｒｔＲｅｐ中包含新的证书。如果拒绝请求，报文中包含错误代码。（见６． ６． ２ ）ＣＡ支持自我注册证书请求， 此时请求实体还不是证书持有者。ＣＡ要求请求实体利用带外方式从ＲＡ获得的秘密产生认证信息。这一认证信息代替ＲＡ的签名保证请求者的身份是经过ＲＡ核实的。以带外方式从ＲＡ获得的秘密可以用来产生ｍａｃ或者带密钥的散列函数的对称密钥。请求实体产生ＧＢ／Ｔ １９７７１－２００５ＣｅｒｔＲｅｑ消息并且用相应的私钥签名。这一消息利用从ＲＡ获得的秘密加以保护。之后，ＣＡ产生Ｃｅｒ－ｔＲｅｐ消息，如果请求消息正确，则ＣｅｒｔＲｅｐ中包含新的证书。如果拒绝请求，报文中包含错误代码。（见６． ６． ３和６．６．４）ＣＡ处理以Ｃｅｒ ｔＲｅｑ消息形式出现的证书更新请求。这种消息被请求实体发到ＣＡ。这个消息包括证书持有者的标识名，当前证书的序列号，新的公钥以及拥有相应私钥的证明。消息可以包括预定的有效期和建议的密钥ｉｄ。这个消息可用证书持有者的有效证书（未过期，未被撤销）私钥签署。ＣＡ用ＣｅｒｔＲｅｐ消息回复申请者。这个消息包含一个新证书或者错误代码。如果颁发新证书的话，证书中将包含证书持有者的标识名和新的公钥。ＣＡ可以自由修改请求中的合法期限。如果申请消息中没有密钥标识符，ＣＡ将产生一个（见６．６．５）０ＣＡ应该接收从ＲＡ发来的Ｒｅ ｖＲｅｑ消息。ＲｅｖＲｅｑ消息应该包括证书序列号或证书持有者的标识名。ＣＡ用ＲｅｖＲｅｐ消息回应。这个消息应该包括状态和失败信息，也可以包括撤销证书的附加细节。ＣＡ支持由第三方集中产生密钥对（并通过带外方式提供给ＣＡ）的加密证书请求。支持对第兰方 集中产生的密钥对颁发加密证书的ＣＡ要处理ＣｅｒｔＲｅｑ消息形式的请求。这些消息由请求证书的终端实体发送给ＣＡ。这些消息应当包括证书持有者的可辨别名，当前证书的序列号。可选的，该消息可包括一个有效期。该消息用证书持有者的未过期，未被撤销的签名证书的相应私钥签名。之后ＣＡ以ＣｅｒｔＲｅｐ消息的形式响应请求者。该消息包括新证书和加密私钥，或是错误代码。如果颁发证书的话，该证书就包括证书持有者的可辨别名和新的公钥。ＣＡ可以随意修改请求中希望的有效期。ＣＡ应该把ＣＡ证书、交叉证书对、ＣＲＬ以及它颁发的终端实体的加密证书放入资料库。 ５．３注册机构（ＲＡ）５．３．１概述 ＲＡ保证请求证书的实体的身份。ＲＡ可以通过要求实体用物理令牌来和ＲＡ进行物理上的接触或通过带外机制来验证身份。当实体物理上接触ＲＡ时，ＲＡ也要通过验证一个被签名的消息来验证它们拥有与公钥相应的私钥材料（见６．６．２）０ ＲＡ应该验证实体拥有一个完整的密钥对。在密钥对和实体身份被验证之后，ＲＡ签署并发送一个电子证书请求给相应的ＣＡ ａ没有与ＲＡ进行过物理接触的证书请求者，在进行证书请求时，必须具有ＲＡ提供给他的认证信 息。这一信息用于实体在自我注册请求中向ＣＡ证明自己的身份。本标准不对实现自我注册请求的带外事务的格式和内容进行规定。 ＲＡ可以对ＣＡ授权它们管理的实体证书请求证书撤销。ＲｅｖＲｅｑ的格式在６． ６． ７中定义。ＲＡ功能可以与ＣＡ在一起也可以在一个不同的设施中执行。ＲＡ本身既包括证书持有者的功能—请求、撤销和更新由ＣＡ颁发的证书（它得是该证书的主 体）（见５．４），又包括客户的功能—检索证书和ＣＲＩ．以及验证证书认证路径（见５．５）０５．３．２与互操作性有关的ＲＡ功能要求ＲＡ应该执行下列功能： 接受和验证证书请求； 向ＣＡ发送证书请求； 从资料库检索证书和ＣＲＬ； 产生证书撤销请求。 ＲＡ应该能够连同ＣＡ的证书一起把新签署的证书发给证书持有者。ＲＡ应该可以代表不再拥有它们的私钥并且怀疑该私钥己泄露的证书持有者产生并签署证书撤销 请求（丢失而并不认为已泄露的签名密钥不是必须被撤销；这由策略决定。注意丢失的保密性的密钥无论如何都必须被撤销，否则发送方就会加密和传输接受方无法解秘的消息）。如果ＣＡ的认证业务说明允许，ＲＡ也应该可以代表证书持有者的组织产生并签署证书撤销请求。撤销请求由后来把它们发送ＧＢ／Ｔ １９７７１－２００５给颁发证书的ＣＡ的ＲＡ所签署。５．３．３事务集合ＲＡ所用电子事务能够实现终端实体证书的请求、发送和撤销，以及为了验证签名而从资料库中检 索证书和ＣＲＩ．。下面将给出这些事务的一个概括；它们将在６． ６中具体地描述。ＲＡ接收来自潜在证书持有者的Ｃｅ ｒｔＲｅｑ格式的证书请求。ＣｅｒｔＲｅｑ消息被潜在证书持有者在ＰＫＩＰｒｏｔｅｃｔｉｏｎ结构中所签署。在审查了请求者的凭证并确认该潜在证书持有者拥有相应的私钥之后，ＲＡ抽取公钥信息并且用ＲＡ的名字和签名建立一个新的ＣｅｒｔＲｅｑ消息。ＲＡ把该消息发送给ＣＡ．ＲＡ应该可以向证书持有者提供该ＣＡ的证书。 ＲＡ可以从ＣＡ接收ＣｅｒｔＲｅｐ消息。如果证书请求被拒绝，ＲＡ将审查从ＣＡ发来的错误代码并可能会发送一个新的请求。如果一个证书请求被接受了，ＲＡ可以向证书持有者提供新的证书。 ＲＡ应该在不再拥有它们自己私钥的证书持有者或证书持有者所在组织的要求下，产生撤销请求。通过签署这个请求，ＲＡ保证请求者的身份。ＲＡ应该可以产生ＲｅｖＲｅｑ消息，包括证书序列号或证书持有者的可辨别名。这个ＲｅｖＲｅｑ消息应该被一个ＲＡ所签署。ＣＡ应该用ＲｅｖＲｅｐ消息回应ＲＡｏ 这个消息应该包括状态和失败信息，并且可以包括关于被撤销证书的附加细节。如果证书被撤销了，ＲＡ应该提供这个信息给请求者。如果请求被拒绝了，ＲＡ将审查错误代码并且可能再产生该请求。５．４证书持有者规范５．４．１概述ＰＫＩ为证书持有者提供证书管理功能。证书持有者包括ＣＡｓ，ＲＡｓ和其他的终端实体。终端实体 可能是个人用户和计算机系统（例如路由器和防火墙），也可能是应用程序（ＣＡｓ和ＲＡｓ除外）。ＰＫＩ证书持有者生成签名并且支持ＰＫＩ事务来获取、更新和撤销他们的证书。 ５．４．２与互操作性相关的ＰＫＩ证书持有者功能要求证书持有者的功能： 生成签名； 生成证书请求；请求证书撤销； 请求证书更新（可选项）。 证书持有者同时也是客户，因此它也具备５． ５中定义的客户功能。５．４．３证书持有者事务集合证书持有者的事务能使证书持有者请求新的证书，以及撤销当前持有的证书。所有的证书持有者 事务都由发放证书的ＣＡ及其ＣＡ授权的ＲＡ执行。证书持有者应该能够请求撤销他们自己的证书。这个事务由ＣＡ执行，允许证书持有者签署他们 的证书撤销请求。证书持有者为每个他们希望撤销的证书产生一个ＲｅｖＲｅｑ消息并发送给ＣＡｏＲｅｖＲｅｑ消息要包括撤销原因。ＣＡ产生ＲｅｖＲｅｐ消息并返还给证书持有者。这个事务过程在６．６．７中有详细描述。可选的，证书持有者能够实现证书更新请求。这个事务由ＣＡ执行，允许证书持有者签署自己的证 书请求（不需要ＲＡ验证其身份）。ＣＡ可以支持该项事务，但是它的具体使用由认证业务说明决定。在不与ＲＡ交互的情况下请求一个新的证书，证书持有者产生一个ＣｅｒｔＲｅｑ消息，并且使用新的和当前的私钥进行签名。ＣＡ产生ＣｅｒｔＲｅｐ消息，如果请求成功，就包含一个新的证书。如果请求被拒绝，就包含错误代码。证书持有者能够实现自我注册的证书请求。 证书持有者也可以实现加密证书请求。在此事务中，证书持有者产生一个证书请求，说明希望的密 钥管理算法，并用一个有效的签名密钥对该请求签名。ＣＡ响应一个证书和加了密的私钥或是错误代码。ＧＢ／Ｔ １９７７１－２００５５．５客户规范５．５．１客户概述ＰＫＩ客户使用ＰＫＩ来为证书持有者和证书使用者，包括ＣＡ和其他的终端实体提供证书处理功 能。终端实体也可以包括ＲＡ，个人用户和计算机系统（如路由器和防火墙）。在最小意义上， ＰＫＩ客户验证签名，获得证书和ＣＲＬｓ，并验证证书认证路径。同时具有证书持有者身份的客户也能产生签名，也可以支持撤销或更新证书的ＰＫＩ事务。５．５．２与互操作性相关的ＰＫＩ客户功能要求 客户的最小功能集合：验证签名； 从查询服务器中检索证书和ＣＲＬｓ ；验证证书认证路径。 ５． ５． ３ ＰＫＩ客户事务集合客户事务使客户能从资料库中获得证书和ＣＲＩ ，ｓ。所有的事务都与证书资料库有关。所有的客户必须支持以下事务： 检索证书—这个事务允许一个用户利用ＬＤＡＰ绑定目录服务或指定资料库，并根据主体名或证书序列号和颁发者的名字检索证书； 检索ＣＲＩ ．—这个事务允许一个用户利用ＬＤＡＰ绑定目录服务或指定资料库，来检索一个特定ＣＡ的当前ＣＲＬ或是某个特定的ＣＲＬ。所有的客户都必须支持轻型目录访问协议 Ｍ ＤＡＰ），以检索证书和ＣＲＬｓ。事务的详细规定参见ＲＦＣ１７７７ ０６数据格式６．１数据格式概述 必须为ＰＫＩ组件之间的互操作定义基本的数据格式。数据格式包括证书、ＣＲＬ和事务格式。本标准包括了ＰＫＩ组件之间、ＰＫＩ ｃｌｉｅｎｔ和ＰＫＩ组件之间所有事务的数据格式。６．２证书格式本标准使用ＧＢ／Ｔ １６２６４． ８－２００５的证书格式。虽然ＩＴＵ－Ｔ建议的Ｘ． ５０９的修订版没有公布，但版本３的格式已经被广泛采用，并且ＡＮＳＩ的Ｘ９． ５５和ＩＥＴＦ的ＲＦＣ ２４５９都对其作了详细说明。ＧＢ／Ｔ １６２６４． ８－２００５的证书包括以下内容： Ｖｅｒｓｉｏｎ版本；Ｓｅｒｉ ａｌ Ｎｕｍｂｅｒ证书序列号；Ｉ ｓｓｕｅｒ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ颁发者签名算法；Ｉ ｓｓｕｅｒ Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ颁发者可辨别名；Ｖａｌ ｉｄｉｔｙ Ｐｅｒｉｏｄ证书有效时间； Ｓｕｂｊｅｃｔ Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ主体可辨别名；Ｓｕｂｊ ｅｃｔ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｏｒｍａｔｉｏｎ主体公钥信息； Ｉｓｓｕｅｒ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ颁发者唯一标识符（可选，本标准不使用）；Ｓｕｂｊ ｅｃｔ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅ：主体唯一标识符（可选，本标准不使用）；Ｅｘｔｅｎｓｉ ｏｎｓ证书扩展（可选）；Ｉ ｓｓｕｅｒｓ Ｓｉｇｎａｔｕｒｅ ｏｎ ａｌｌ ｔｈｅ ａｂｏｖｅ ｆｉｅｌｄｓ颁发者对以上所有域的签名。６．２． １证书字段 Ｘ． ５０９证书语法的ＡＳＮ． １定义见附录Ａ。出于签名考虑，证书用ＡＳＮ． １ ＤＥＲ编码表示。ＡＳＮ． １ＤＥＲ是一个为每个元素赋予标签、长度和值的编码系统。详见ＩＳＯ／ＩＥＣ ８８２５．１－２００２．以下介绍ＧＢ／Ｔ １６２６４． ８－－－－－２００５的证书。除了可选的ｓｕｂｊｅｃｔＵｎｉｑｕｅＩＤ和ｉｓｓｕｅｒＵｎｉｑｕｅｌＤ字段，ＧＢ／Ｔ １９７７１－２００５ＣＡ应该产生下面这些字段，而且客户根据ＧＢ／Ｔ １６２６４． ８－２００５可以处理它们。ＣＡ可以不颁发包括ｉｓｓｕｅｒＵｎｉｑｕｅＩＤ和ｓｕｂｊｅｃｔＵｎｉｑｕｅｌＤ的证书。客户也可以不处理ｓｕｂｊｅｃｔＵｎｉｑｕｅＩＤ和ｉｓｓｕｅｒＵｎｉｑｕｅＩＤ ｏ他们可以拒绝那些含有这两部分字段的证书。ａ） Ｖｅｒｓｉｏｎｖｅｒｓｉ ｏｎ字段表示证书的版本号。该字段的值应为２，以表示版本３证书。ｂ） Ｓｅｒｉａｌ Ｎｕｍｂｅｒ ｓｅｒｉａｌＮｕｍｂｅｒ是ＣＡ给每个证书分配的一个整数。对一个给定的ＣＡ，它提供的证书序列号应该是唯一的（即， 颁发者和证书序列号唯一标识一个证书）。ｃ） Ｓｉｇｎａｔｕｒｅｓ ｉｇｎａｔｕｒｅ字段包含了一个算法标识符，用于表示签署证书的算法。此字段包括一个ａｌｇｏｒｉｔｈ－ｍＩｄｅｎｔｉ ｆｉｅｒ，用于传递参数。在６． ２． ２． ２中列出了ａｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ的内容。证书不应该使用ｓ ｉｇｎａｔｕｒｅ字段去传递参数（看下面的Ｓｕｂｊｅｃｔ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｏｒｍａｔｉｏｎ），因为该字段没有被 颁发者的签名保护。ｄ） Ｉｓｓｕｅｒ Ｎａｍｅ ｉｓｓｕｅｒ Ｎａｍｅ字段提供了签署证书机构的全球唯一标识符。颁发者的名字是一个Ｘ． ５００标识名。该标识名由属性类型和属性值组成。通常属性类型由Ｘ． ５００系列建议定义，属性值为Ｄｉ ｒｅｃｔｏｒｙＳｔｒｉｎｇ类型。Ｄｉ ｒｅｃｔｏｒｙＳｔｒｉｎｇ可选择ＰｒｉｎｔａｂｌｅＳｔｒｉｎｇ， Ｔｅｌｅｔｅｘ５ｔｒｉｎｇ， ＢＭＰＳｔｒｉｎｇ， ＵｎｉｖｅｒｓａｌＳｔｒｉｎｇ和 Ｕｔｆ８Ｓｔｒｉｎｇ中的一种。ＰｒｉｎｔａｂｌｅＳｔｒｉｎｇ是一个基本拉丁字符集，可使用大小写字母，数字和少量特殊字符。Ｔｅｌ ｅｔｅｘＳｔｒｉｎｇ是ＰｒｉｎｔａｂｌｅＳｔｒｉｎｇ的扩展集，在拉丁字符中加人了重音符和日本字符。ＢＭＰＳｔ ｒｉｎｇ是双字节字符集，它满足绝大多数的欧洲字符集。ＵｎｉｖｅｒｓａｌＳｔｒｉｎｇ是多字节字符集， 包括了所有的主要字符集。Ｕｔｆ８Ｓｔｒｉｎｇ是ＵｎｉｖｅｒｓａｌＳｔｒｉｎｇ的替代编码。当创建新名字时，ＣＡ要从Ｐｒｉ ｎｔａｂｌｅＳｔｒｉｎｇ， ＢＭＰＳｔｒｉｎｇ，和Ｕｔｆ８Ｓｔｒｉｎｇ里选择最严格的类型来创建Ｄｉ ｒｅｃｔｏｒｙＳｔｒｉｎｇ。也就是说，仅需基本拉丁字符的ＡｔｔｒｉｂｕｔｅＶａｌｕｅ一般就使用Ｐｒｉｎｔ－ａｂｌ ｅＳｔｒｉｎｇ。包含重音符拉丁字符的ＡｔｔｒｉｂｕｔｅＶａｌｕｅ就使用ＢＭＰＳｔｒｉｎｇ。当ＢＭＰＳｔｒｉｎｇ字符 ｆ集不够用时才使用Ｕｔ８Ｓｔｒｉｎｇ，仍然保留Ｔｅｌ ｅｔｅｘＳｔｒｉｎｇ，和ＵｎｉｖｅｒｓａｌＳｔｒｉｎｇ是为了向后兼容性的需要，不应该在新主体的证书中使用它们。但是， 此种类型可能会在已经颁发的证书中使用。Ｃｌｉｅｎｔｓ可能会收到使用这些类型的证书。 ｓｓｕｅｒＡｌ可选的名字可放在ｉｔＮａｍｅ扩展字段，一些ＧＢ／Ｔ １６２６４． ８－２００５证书的使用者希望ｉ ｓｓｕｅｒ字段为空。然而，遵从本标准的证书中的这个字段都含有Ｘ． ５００的可辨别名。ｅ） Ｖａｌｉｄｉｔｙｖａｌ ｉｄｉｔｙ字段说明了证书开始生效的日期（ｎｏｔＢｅｆｏｒｅ）和变成无效的日期（ｎｏｔＡｆｔｅｒ） ｏ ｖａｌｉｄｉｔｙ字段的时间表示形式用ＵＴＣＴｉ ｍｅ或ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅｏ 对于１９５０年到２０４９年（含）的日期，ｖａｌｉｄｉｔｙ字段一般使用ＵＴＣＴＴｉｍｅｏ ＵＴＣＴＴｉｍｅ使用格林威治时间，而且要精确到秒。秒要清楚表示，即使为零。ＵＣＴＣＴｉ ｍｅ的格式为ＹＹＭＭＤ－ＤＨＨＭＭＳＳＺ， 年字段做如下规定： １）如果ＹＹ等于或大于５０，年代为１９ＹＹ； ２）如果ＹＹ小于５０，年代为２０ＹＹｏ对于２０５０年以后的日期，ｖａｌ ｉｄｉｔｙ字段一般用ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅｏ ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅ使用格林威治时间，而且要精确到秒。秒要清楚表示，即使为零。Ｇｅｎｅｒａｌ ｉｚｅｄＴｉｍｅ的格式为ＹＹＭＭＤ－ＤＨＨＭＭＳＳＺ． ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅ不能包括分秒。（１９５０年前的日期对本标准来说无效，所以ＧＢ／Ｔ １９７７１－２００５ 不予考虑。）ｆ） Ｓｕｂｊｅｃｔ Ｎａｍｅ ｓｕｂｊｅｃｔ Ｎａｍｅ字段的目的是给证书主体提供唯一的标识符。主体名使用Ｘ． ５００可辨别名。像在ｉ ｓｓｕｅｒ ｎａｍｅ中描述的一样，在构建ＤｉｒｅｃｔｏｒｙＳｔｒｉｎｇ时ＣＡ使用最严格的选择。可替代的名字可放在ｓｕｂｊ ｅｃｔＡｌｔＮａｍｅ扩展中，ＧＢ／Ｔ １６２６４． ８－２００５证书的使用者希望本字段为空。然而，遵从本标准的证书都在这个字段里带有主体的Ｘ． ５００可辨别名。 ｇ） Ｓｕｂｊｅｃｔ Ｐｕｂｌｉｃ Ｋｅｙ ＩｎｆｏｒｍａｔｉｏｎＳｕｂ ｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ字段是用来携带公钥和公钥使用的算法的。它包括ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙ字段和ａｌ ｇｏｒｉｔｈｍ１ｄｅｎｔｉｆｉｅ：字段，ａｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ字段有ａｌｇｏｒｉｔｈｍ ａｎｄ ｐａｒａｍｅｔｅｒｓ次级 字段。ｈ） Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒｓ证书里的ｓｕｂｉ ｅｃｔＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅ：和ｉｓｓｕｅｒＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ字段是用来处理主体名和颁发者名被过时重用的可能性。ＣＡ不会颁发含有这些唯一标识符的证书。ＰＫＩ客户也不会被要求 去处理含有这些标识符的证书。当然，如果它们不处理这些字段，他们会拒绝包含这些字段 的证书。 ｉ ） Ｅｘｔｅｓｉｏｎｅｘｔ ｅｎｓｉｏｎ字段的增加是ＧＢ／Ｔ １６２６４． ８－２００５证书最主要的改变。扩展有三部分：ｅｘｔｎＩｄ，标识该扩展，ｃｒｉ ｔｉｃａｌ，说明该扩展是ｃｒｉｔｉｃａｌ或ｎｏｎｃｒｉｔｉｃａｌ的，ｅｘｔｎＶａｌｕｅ，扩展值。一个证书可以 包括任意多个扩展字段，其中也包括局部定义的扩展。如果设置了ｃｒｉｔｉｃａｌ标志，就要求客户或者能够处理该扩展字段，或者不能验证该证书。 在ＧＢ／Ｔ １６２６４． ８－２００５中有完整的扩展标准。６． ２． ３详述了这些标准扩展在本标准中的使用。 ｊ ）Ｉｓｓｕｅｒ＇ｓＳｉ ｇｎａｔｕｒｅ实际的证书签名使用ＳＩ ＧＮＥＤ参数类型，扩展为被签名的数据的ＳＥＱＵＥＮＣＥ（例如，证书）， 算法标识符，以及一个ＢＩＴ ＳＴＲＩＮＧ形式的实际签名。ａｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ标识了用来对证书签名的算法。尽管这个ａｌ ｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ字段包括了一个ｐａｒａｍｅｔｅｒｓ字段，在理论上可以用来传递签名算法的参数（ 见６． ２． ２． ３ ），但它本身并不是一个被签名的对象。ｐａｒａｍｅｔｅｒｓ字段不能用来传递参数。当需要获得验证签名的参数时，应当从颁发证书的ＣＡ的证书的ｓｕｂｊｅｃｔ －Ｐｕｂｌ ｉｃＫｅｙＩｎｆｏ字段中获得相应参数。６．２．２加密算法６．２．２． １加密算法概述 本标准使用四类算法：散列函数、数字签名算法、消息认证算法和对称加密算法。当描述数字签名算法时，通常与散列函数一起介绍。当描述证书中的公钥时，散列函数被忽略。这就允许当散列函数被另一个更强的算法替换时，证书也能使用。 要求一个ＰＫＩ组件至少应该实现其中一个数字签名算法。对于简单的ＰＫＩ客户组件来说，能验证由其中一个算法生成的签名已经足够了；要求其他的组件能够产生和验证由其中一个算法生成的签名。遵守本标准的ＰＫＩ组件应该支持一个加密算法。 允许相应的组件使用额外的算法，甚至当它们不能使用所有的这些算法时。比如，支持这里的一个密钥协定算法的客户可以使用别的密钥传递算法，即使它不支持这里的密钥传递算法。６．２．２．２散列函数 散列函数用于为证书和ＣＲ工Ｊ产生数字签名，它也用于将共享秘密散列为报文确认码。本标准中建议使用一种散列函数。以ＳＨＡ－１为例，它是通过对象标识符以及数字签名算法表示 的。ＳＨＡ－１的ＡＳＮ． １对象标识符是：ＧＢ／Ｔ １９７７１－２００５ｓｈａｌ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：二｛ ｉｓｏ（１）ｉｄｅｎｔｉｆｉｅｄ－ｏｒｇａｎｉｚａｔｉｏｎ（３） ｏｉｗ（１４） ｓｅｃｓｉｇ（３） ａｌｇｏｒｉｔｈｍ（２） ２６｝只要该对象标识符在算法类型中出现，相应的参数域应该被忽略，如果出现，必须为ＮＵＬＬ． ６．２．２．３数字签名算法ＧＢ／Ｔ １６２６４． ８－２００５中指定了发放证书的签名算法和其他主体的加密算法。这两种算法可以是不同的。本标准以ＲＦＣ ２３１３中的ＲＳＡ算法为例。ＲＳＡ的签名算法在ＲＦＣ ２３１３中定义。ＲＳＡ也可使用几种散列算法。本标准中引用的ＲＳＡ定义为：ｐｋｃｓ－１ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉｓｏ（１）ｍｅｍｂｅｒ－ｂｏｄｙ（２）Ｕ Ｓ（８４０）ｒｓａｄｓｉ （１１３５４９） ｐｋｃｓ（１）１｝ ｓｈａ－ｌＷｉｔｈＲＳＡＥｎｃｒｙｐｔｉｏｎ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｐｋｃｓ－１（１）５｝在ＲＳＡ签署的证书和证书撤销列表中， 它应出现在ＳＩＧＮＥＤ类型中和ｓｉｇｎａｔｕｒｅ字段中。只要实体的标识符作为算法标识符出现，那么参数的值必须是ＮＵＬＩ＿ｏ当证书和证书撤销列表签署时，签名将按下列规则生成和加密：证书和证书撤销列表按ＡＳＮ． １ＤＥＲ加密，并作为ＳＨＡ－１的散列函数的输入。ＳＨＡ－１散列函数的输出为ＯＣＴＥＴ ＳＴＲＩＮＧ并按照ＲＳＡ的加密算法加密。签署证书时，ＲＳＡ生成一个整数ｙｏ ｙ的值按照ＡＳＮ． １的ＢＩＴ ＳＴＲＩＮＧ输出。在ｙ的ｓｉｇｎａｔｕｒｅ字段包含了证书或证书撤销列表。（通常分为两步，整数ｙ先转化为ｏｃｔｅｔ ｓｔｒｉｎｇ。然后再转化为ｂｉｔ ｓｔｒｉｎｇ． ）当ＣＡ发放了一个证书，并且它的ｓｕｂｊ ｅｃｔＰｕｂｌｉｃＫｅｙｌｎｆｏ字段包含了ＲＳＡ的公钥，那么对象标识符ｒｓａＥｎｃｒｙｐｔｉｏｎ将作为ａｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ出现在ｓｕｂｊｅｃｔＰｕｂｌｉｃｋｅｙＩｎｆｏ字段中，来标识ＲＳＡ的公钥。 ｒｓａＥｎｃｒｙｐｔｉｏｎ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｐｋｃｓ－１ １｝只要ｒｓａＥｎｃｒｙｐｔｉ ｏｎ对象标识符在算法类型中出现，那么参数字段必为ＮＵＬＬ， ＲＳＡ的公钥必须为ＡＳＮ． １的ＲＳＡＰｕｂｌｉｃＫｅｙ：的类型。ＲＳＡＰｕｂｌ ｉｃＫｅｙ：：＝ＳＥＱＵＥＮＣＥ｛ｍｏｄｕｌ ｕｓ ＩＮＴＥＧＥＲ，一ｎｐｕｂｌ ｉｃＥｘｐｏｎｅｎｔ ＩＮＴＥＧＥＲ一ｅ）系数为ｎ， ｐｕｂｌｉｃＥｘｐｏｎｅｎｔ为公共指数ｅ， ＲＳＡＰｕｂｌｉｃＫｅｙ编码后为ＢＩＴ ＳＴＲＩＮＧ ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙ的值。ＲＳＡＰｕｂｌ ｉｃＫｅｙ既出现在ＲＳＡ的签名密钥中，也在ＲＳＡ的加密密钥中出现。虽然不禁止只使用一个密钥来进行加密和签名，但不提倡这样做。６．２．２．４消息认证算法 本标准建议支持两种消息认证算法。以ＤＥＳ－ＭＡＣ和ＳＨＡ１－ＭＡＣ为例，推荐使用ＳＨＡＴ－ＭＡＣ，ＤＥＳ－ＭＡＣ是为了保证向后的兼容性。ＳＨＡ１－ＭＡＣ 本算法通过为数据计算一个ＳＨＡ－ ｉ ＨＭＡＣ值（在ＲＦＣ２１０４中详细定义）而提供完整性保护。它的算法标识符如下：ＳＨＡ１一ＨＭＡＣ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛１３６１５５８１２｝本标准中使用的ｍａｃ长度为９６ｂｉ ｔｏＤＥＳ－ＭＡＣ 本算法通过为数据计算一个ＤＥＳ ＭＡＣ值（在ＦＩＰＳ－１１３中详细定义）而提供完整性保护。它的算法标识符如下：ＤＥＳ－ＭＡＣ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉ ｓｏ（１）ｉｄｅｎｔｉｆｉｅｄ－ｏｒｇａｎｉｚａｔｉｏｎ（３） ｏｉｗ（１４） ｓｅｃｓｉｇ（３） ａｌｇｏｒｉｔｈｍ（２） １０ＧＢ／Ｔ １９７７１－２００５一ＭＡＣ的长度是一个整数型的参数，在本标准中限制为３２｝ 参数域包含一个整数，表明了ＭＡＣ的长度，在本标准中规定该值取为３２０６．２．２．５对称加密算法本标准使用了对称密钥算法来实现挑战一响应协议和保护私钥传输。在本标准中，以使用ｔ ＤＥＡ（Ｔｒｉｐｌｅ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｌｇｏｒｉｔｈｍ）算法的ＥＣＢ模式为例说明对称密钥算法的使用。ｔ ＤＥＡ算法在ＡＮＳＩ Ｘ９． ５２中定义。ｔＤＥＡ算法基于ＤＥＳ算法，使用３个５６ ｂｉｔ的密钥：Ｋｌ，Ｋ２和Ｋ３。在本标准中，使用双密钥模式，Ｋ１＝Ｋ３ｅ ｔＤＥＡ算法的密钥绝对不能出现在ＧＢ／Ｔ １６２６４． ８－２００５证书中。有的情况下，会在ＰＫＩＭｅｓｓａｇｅ中传输ｔＤＥＡ的密钥，这时候，ｔＤＥＡ的密钥必须是经过加密的。下文说明了ｔＤＥＡ的双密钥、ＥＣＢ模式的加密方法和密钥的编码格式。 ｔ ＤＥＡ算法有ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ，而且要有ｔＥＣＢ的ＯＩＤ。双密钥选项在ＥＣＢＰａｒａｍｓ结构中指明。ＡＳＮ． １表示如下：ＴＤＥＡＩ ｄｅｎｔｉｆｉｅｒ：：＝ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ（｛ＴＤＥＡＭｏｄｅｓ｝｝ ＴＤＥＡＭｏｄｅｓ ＡＬＧＯＲＩＴＨＭ－ＩＤ：：二｛｛ＯＩＤ ｔＥＣＢ ＰＡＲＭＳ ＥＣＢＰａｒｍｓ｝｝一ｍｏｄｅ １一｛ＯＩＤ ｔＣＢＣ ＰＡＲＭＳ ＴＤＥＡＰａｒｍｓ｝｝一ｍｏｄｅ ２一｛ＯＩＤ ｔＣＢＣ－Ｉ ＰＡＲＭＳ ＴＤＥＡＰａｒｍｓ｝｝一ｍｏｄｅ ３一 ｛ＯＩＤ ｔＣＦＢ ＰＡＲＭＳ ＣＦＢＰａｒｍｓ｝｝一ｍｏｄｅ ４一｛ＯＩＤ ｔＣＦＢ－Ｐ ＰＡＲＭＳ ＣＦＢＰａｒｍｓ）｝一ｍｏｄｅ ５一｛ＯＩ Ｄ ｔＯＦＢ ＰＡＲＭＳ ＴＤＥＡＰａｒｍｓ｝｝一ｍｏｄｅ ６一｛ＯＩＤ ｔＯＦＢ－Ｉ ＰＡＲＭＳ ＴＤＥＡＰａｒｍｓ｝，一ｍｏｄｅ ７一｝ ＥＣＢＰａｒｍｓ：：＝ＴＤＥＡＰａｒｍｓ （ＷＩＴＨ ＣＯＭＰＯＮＥＮＴＳ｛·一ｉ ｖＧｅｎｅｒａｔｉｏｎ ＡＢＳＥＮＴ｝） ＴＤＥＡＰａｒｍｓ：：＝ＳＥＱＵＥＮＣＥ｛ｋｅｙｉ ｎｇ０ｐｔｉｏｎｓ Ｋｅｙｉｎｇ０ｐｔｉｏｎｓ ＯＰＴＩＯＮＡＬ，ｉ ｖＧｅｎｅｒａｔｉｏｎ ［０］ ＩＶＧｅｎｅｒａｔｉｏｎ ＯＰＴＩＯＮＡＬ｝ 一本标准中只支持双密钥 Ｋｅｙｉｎｇ０ｐｔｉｏｎｓ：：＝ＢＩＴ ＳＴＲＩＮＧ｛ｏｐｔｉ ｏｎ－１ （０），一（３－ｋｅｙ） Ｋ１，Ｋ２ ａｎｄ Ｋ３ ａｒｅ ｉｎｄｅｐｅｎｄｅｎｔ ｋｅｙｓｏｐｔｉ ｏｎ－２ （１），一（２－ｋｅｙ） Ｋ１ ａｎｄ Ｋ２ ａｒｅ ｉｎｄｅｐｅｎｄｅｎｔ ａｎｄ Ｋ３＝Ｋ１ｏｐｔｉ ｏｎ－３ （２）一（１－ｋｅｙ） Ｋｌ＝Ｋ２＝Ｋ３） ｉ ｄ－ａｎｓｉ－ｘ９５２ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉ ｓｏ（１）ｍｅｍｂｅｒ－ｂｏｄｙ（２） ｕｓ（８４０） ａｎｓｉ－ｘ９５２（１００４７）｝Ｓｅｃｏｎｄ ＣＲＡＤＡ Ｄｒａｆｔ，Ｖｅｒｓｉｏｎ ２ｍｏｄｅ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉｄ－ａｎｓｉ－ｘ９５２ １｝ｔＥＣＢ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｍｏｄｅ １｝有的情况下，需要对ｔ ＤＥＡ的密钥进行编码，就是两个密钥的直接串接。ＴｗｏＫｅｙｓ二［Ｋ１｝Ｋ２］，ＴｗｏＫｅｙｓ的最高位比特是Ｋｌ的最高位比特。ＧＢ／Ｔ １９７７１－２００５６．２．３证书扩展６．２．３． １证书扩展概述在ＧＢ／Ｔ １６２６４． ８－２００５中定义了一套标准扩展集合。扩展由三部分组成：扩展名称、关键性标识位和扩展取值。在ＧＢ／Ｔ １６２６４． ８－２００５中做了如下规定：客户如果不能处理设置了关键性标识位的扩展，就不能验证证书是否有效。标准化的扩展可以分为四类：密钥和策略信息；主体和颁发者的特征；验证路径限制；ＣＲＬ标识 扩展。６．２．３．２密钥和策略信息 此类扩展用于区分特定的公钥和证书，它们可以用于区别具有多个证书的证书认证机构（ＣＡ）中某一特定的公钥／证书，有助于客户查找某个特定的ＣＡ证书，以便建立验证路径。这些扩展可以限制密钥用途，提供ＣＡ证书中关于策略映射的信息。ａ）权威密钥标识符 扩展ａｕｔ ｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒ提供了一种区别签名证书的特定私钥的手段，标识性信息既可以 基于密钥标识符，也可以基于颁布者名字和序列号。在本标准中，使用密钥标识符的方法。本扩展用于具有多个签名密钥的颁发者（既可能是多个密钥对，也可能是正在进行密钥更换），证 书认证机构（ＣＡ）应当能够产生本扩展，而且客户应能查找和验证具有多个数字签名密钥的证书颁发者ＣＡ的验证路径。建议客户既能够处理密钥标识符，又能够处理由证书颁发者和证 书序列号组成的密钥标识符，便于找到验证路径。 ｂ）主体密钥标识符本字段用于区别一个主体所拥有的多个密钥，在每个已颁发的证书中都应当包含本字段，本 扩展应当是非关键的。 ｃ）密钥用途 扩展ｋｅｙＵｓａｇｅ定义了证书中密钥在使用上的限制，这种限制是基于策略和／或用途的（如签名， 加密）。ＣＡ应当能产生该扩展，而客户应当能处理该扩展。如果ｋｅｙＵａｓｇｅ定义为ＢＩＴＳＴＲＩＮＧ， 所有遵从本标准的ＣＡ都应当在终端实体证书中设置一个值，例如，一个终端实体 证书中的ＫｅｙＵｓａｇｅ不应当既是ｄｉｇｉｔａｌＳｉｇ ｎａｔｕｒｅ又是ｄａｔａＥｎｃｉｐｈｅｒｍｅｎｔ，本扩展应当设置为关键性的扩展。 ｄ）私钥使用期限 扩展ｐｒ ｉｖａｔｅＫｅｙＵｓａｇｅＰｅｒｉｏｄ仅适用于数字签名密钥。在私钥使用期限之外的签名是无效 的，ＣＡ可以产生此扩展，但客户不要求处理此扩展。ｅ）扩展的密钥使用范围 扩展ｅｘｔ ｅｎｄｅｄＫｅｙＵｓａｇｅ用于定义在应用中对证书密钥的使用限制，如果使用此扩展，就不考虑互操作的因素。符合本标准的ＰＫＩ组件不要求支持该扩展。 ｆ）证书策略 扩展ｃｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ包括一个或多个对象标识符（ＯＩＤｓ），每个ＯＩＤ代表颁发本证书的一个策略。ＣＡ应当能够产生带有一个或多个证书策略ＯＩＤ的证书，ＣＡ应当支持一个特殊策略 ＯＩ Ｄ，即任意策略ａｎｙＰｏｌｉｃｙ， ａｎｙＰｏｌｉｃｙ的（）ＩＤ可以认为是一个通用符，能够匹配任何策略。 客户应当能够处理ｐｏｌｉｃｙｌｄｅｎｔｉｆｉｅｒ字段，并与可接受的策略列表（策略列表取决于相应的应用程序）中的标识进行比较。如果提供了一个可接受策略列表，并且至少要有一个列表中的策略 或其映射策略存在于ｃｅｒｔｉ ｆｉｃａｔｅＰｏｌｉｃｙ中时，客户才能验证证书认证路径。如果在证书策略中存在特定策略标识符ａｎｙＰｏｌ ｉｃｙ，并且没有禁止任何策略（见６． ２． ３． ４ ），就可以认为列表中的所有策略都可以接受。 要求符合本标准的组件能处理ｃ ｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｙ的子域ｐｏｌｉｃｙＱｕａｌｉｆｉｅｒｓ，并且支持ｉｄ－ｐｋｉｘ－ｃｐｓＧＢ／Ｔ １９７７１－２００５和ｉ ｄ－ｐｋｉｘ－ｕｎｏｔｉｃｅ（见ＲＦＣ２４５９ ）。符合本标准的ＣＡ不要求能产生该子域。９）策略映射 此非关键性扩展用于ＣＡ证书。它罗列了对象标识符对；每对标识符包括ｉｓｓｕｅｒＤｏｍａｉｎＰｏｌｉｃｙ和ｓｕｂ ｊｅｃｔＤｏｍａｉｎＰｏｌｉｃｙ。它意味着颁发ＣＡ认为其ｉｓｓｕｅｒＤｏｍａｉｎＰｏｌｉｃｙ等价于主体ＣＡ的ｓ ｕｂｊｅｃｔＤｏｍａｉｎＰｏｌｉｃｙ． ＣＡ应当能产生扩展ｐｏｌｉｃｙＭａｐｐｉｎｇｓ，客户也应能够处理该扩展。６．２．３．３证书主体和颁发者特征扩展ｓ ｕｂｊｅｃｔＡｌｔＮａｍｅ， ｉｓｓｕｅｒＡｌｔＮａｍｅ， ｓｕｂｊｅｃｔＤｉｒｅｃｔｏｒｙＡｔｔｒｉｂｕｔｅｓ和ａｕｔｈｏｒｉｔｙ］ ｎｆｏｒｍａｔｉｏｎＡｃｃｅｓｓ都是非关键性的。它们提供了关于主体和颁发者的其他名称和特征的附加信息。ａ）别名 ｓｕｂｊ ｅｔＡｌｔＮａｍｅ和ｉｓｓｕｅｒＡｌｔＮａｍｅ扩展提供了证书主体和证书颁发者的附加信息，这些附加信息包括ＲＦＣ８２２名称（电子邮件地址），ＤＮＳ名称和统一资源标识符（ＵＲＩ）。扩展中可以包 括多个名称。如果需要在证书中提供这些信息， 就应当使用扩展ｓｕｂｊｅｃｔＡｌｔＮａｍｅ和ｉｓｓｕｅｒ－Ａｌ ｔＮａｍｅ ｏ 根据本标准，扩展ｓｕｂｊｅｃｔＡｌｔＮａｍｅ和ｉｓｓｕｅｒＡｌｔＮａｍｅ应当是非关键的。识别这些扩展的应用没有必要能支持所有可能的选择。如果应用不能识别证书中的别名， 就可以忽略该扩展。在本标准中，扩展ｉ ｓｓｕｅｒＡｌｔＮａｍｅ中包括ＵＲＩ信息，ＵＲＩ明确了颁发者证书的位置，这可以用 来验证数字证书中的签名。在本标准中没有规定ｓｕｂｊｅｃｔＡｌｔＮａｍｅ中包含的信息的意义。如果证书认证机构（ＣＡ）的证书不能从Ｘ． ５００目录服务中得到，ＣＡ就应当在证书中的别名扩展中包含相应的ＵＲＩ信息，以指出签名者证书的位置。要求客户能处理ＵＲＩ别名格式，必须 能够识别ＬＤＡＰ ＵＲＬ［ＲＦＣ１９５９］。不要求客户能识别其他ＵＲＩ格式。ｂ）主体目录属性 扩展ｓｕｂｊ ｅｃｔＤｉｒｅｃｔｏｒｙＡｔｔｒｉｂｕｔｅｓ可以包含任何关于主体的Ｘ． ５００目录属性信息。本扩展是非关键性的。本扩展的实现和使用是可选的。 ｃ）权威机构信息存取 扩展ａｕｔｈｏｒｉｔｙＩｎｆｏｒｍａｔｉｏｎＡｃｃｅｓｓ中保存如何获得颁发ＣＡ和服务的信息。信息和服务可以包括在线验证服务和ＣＡ策略数据。（ ＣＲＩ，的位置信息不在本扩展域显示，该信息由ｃＲＬＤｉｓ－ｔ ｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展提供。）６．２．３．４验证路径限制扩展ｂａ ｓｉｃＣｏｎｓｔｒａｉｎｔｓ， ｎａｍｅＣｏｎｓｔｒａｉｎｔｓ和ｐｏｌｉｃｙＣｏｎｓｔｒａｉｎｔｓ用于限制有效的验证路径。 ａ）基本约束扩展ｂａｓｉ ｃＣｏｎｓｔｒａｉｎｔｓ通过ＣＡ部分的信息指定证书的实体是否是ＣＡ，通过ｐａｔｈｌ．ｅｎＣｏｎ－ｓｔｒａｉ ｎｔ部分的信息指定验证路径的长度。ＣＡ应当在证书中能产生扩展ｂａｓｉｃＣｏｎｓｔｒａｉｎｔｓ，客户也应能够处理本扩展。只有在ＣＡ为Ｔｒ ｕｅ的时候，ｐａｔｈ ＬｅｎＣｏｎｓｔｒａｉｎｔ才有意义。 在所有ＣＡ证书中都应当包括ｂａｓｉｃＣｏｎｓｔｒａｉｎｔｓ扩展，而且ＣＡ应当设置为Ｔｒｕｅ。在终端实体的证书中也可以包括扩展ｂａｓｉ ｃＣｏｎｓｔｒａｉｎｔｓ。如果在终端实体的证书中出现扩展ｂａｓｉｃＣｏｎ－ｓｔｒａｉ ｎｔｓ，它应当是一个空的序列值。在所有ＣＡ证书中的扩展ｂａｓｉｃＣｏｎｓｔｒａｉｎｔｓ应当设置成关键性的。 ｂ）名字约束扩展ｎａｍｅＣｏｎｓｔｒａｉ ｎｔｓ只能用在ＣＡ证书中，它指定证书的验证路径中所有后续证书的名字范围。ＣＡ应当在证书中能产生扩展ｎａｍｅＣｏｎｓｔｒａｉ ｎｔｓ，客户也应能够处理该扩展。该扩展应设置为关键性的。 ｃ）策略约束 扩展ｐｏｌ ｉｃｙＣｏｎｓｔｒａｉｎｔｓ只用于ＣＡ证书。它可以以两种方式对策略解释进行限制：既可以限ＧＢ／Ｔ １９７７１－２００５制策略映射，又可以要求在验证路径中的每个证书包括一个可接受的策略标识符。 ｉ本扩展包括两个字段：ｎｈｉｂｉｔＰｏｌｉｃｙＭａｐｐｉｎｇ和ｒｅｑｕｉｒｅＥｘｐｌｉｃｉｔｐｏｌｉｃｙ。如果ｉｎｈｉｂｉｔＰｏｌｉｃｙＭａｐ－ｐｉ ｎｇ存在，它的值代表验证路径中的策略映射不再有效之前的其他证书的个数。如果ｒ ｅｑｕｉｒｅＥｘｐｌｉｃｉｔＰｏｌｉｃｙ存在，在后续的证书中应当明确包含可接受的策略标识符。ＲｅｑｕｉｒｅＥｘ－ｐｌ ｉｃｉｔｐｏｌｉｃｙ的值代表在验证路径中要求明确的策略前的其他证书的个数。ＣＡ应当在颁发证书中包括本扩展，客户应能够处理本扩展。该扩展应设置为关键性的。 ｄ）禁止ａｎｙＰｏｌｉｃｙ本扩展禁止在今后的证书中使用ａｎｙＰｏｌ ｉｃｙ。此关键性的扩展可以出现在颁发给ＣＡ的证书中。禁止策略意味着特殊策略标识符ａ ｎｙＰｏｌｉｃｙ ＯＩＤ（值为｛｛２ ５ ２９３２。｝）不能和其他证书策略匹配。该扩展的值是Ｉ ＮＴＥＧＥＲ，代表在验证路径中不再允许ａｎｙＰｏｌｉｃｙ之前的其他证书的个数。例如， １意味着ａｎｙ－ｐｏｌｉｃｙ只能在本证书的主体所颁发的证书中处理，在验证路径中的其他证书中不能使用。ＣＡ应当能够产生此扩展，客户应能够处理本扩展。 ６． ２． ３． ５ ＣＲＬ标识扩展本类扩展包含如何获得证书撤销列表（ＣＲＬ）的信息。通过标识ＣＲＩ，和颁发ＣＲＬ者的名称（颁发 者可能不是产生证书的ＣＡ）的方式，可以将大的ＣＲＩ，列表划分为多个小ＣＲＬ列表。 ＣＲＬ分发点：ＣＲＩ， ＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展标识ＣＲＩ、分发点，或指导客户如何验证一个已撤销的证书。本扩展由三部分字段组成：ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ， ｒｅａｓｏｎｓ和ｃＲｌ．Ｉｓｓｕｅｒａａ） ＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ存放如何获得ＣＲＩ，的位置信息。如果本字段缺省，ＣＲＬ分发点的名字就是颁发者名字。在ＣＡ颁发的ＣＲＩ ，很大的情况下，此字段提供了一种将ＣＲ工、划分为多个可管 理片断的机制。ｂ） Ｒｅａｓｏｎｓ存放相应的ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ分发的ＣＲＩ一撤销的原因。如果ｒｅａｓｏｎｓ不出现，在ｄｉｓ－ｔ ｒｉｂｕｔｅＰｏｉｎｔｓ分发的ＣＲＩ，中可以包括由于任何原因而撤销的证书。不要求客户能处理ｒｅａ－ｓｏｎｓ． ｃ） ＣＲＬＩｓｓｕｅｒ确定分发并签名ＣＲＬ的权威机构。如果该字段不出现，ＣＲＬ颁发者与证书颁发者相同。使用本字段可以建立统一的ＣＲＬ，包括由多个ＣＡ颁发的证书。 ＣＡｓ应当能够产生带有ｄｉ ｓｔｒｉｂｕｔｅＰｏｉｎｔ部分的ｃＲＬＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展。如果不能从公共的Ｘ． ５００目录服务中获得ＣＲＩ一列表，ＣＡ应当在ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ中用ＵＲＩ别名格式来标注相应ＣＲＬ列表的位置。要求客户能够处理ｃＲＩ．ＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ扩展。必须能够识别ＵＲＩ格式，至少能够处理ＬＤＡＰ ＵＲＩ格式。如果使用了ｃＲＩ，Ｉｓｓｕｅｒ，要求客户能够使用分发点并验证ＣＲＬ。在６． ３．３中对分发点做进一步的讨论。６．３证书撤销列表６．３．１证书撤销列表概述证书撤销列表（ＣＲＬ）用来列出那些已被撤销或冻结的但并未过期的证书。证书撤销的原因多种多 样，例如日常的管理撤销（当证书的主体离开了发放组织，或责任和证书属性发生了变化），或私钥被泄密。“冻结”是指ＣＡ不再确保证书主体和公钥之间的绑定。Ｘ． ５０９ ｖ２证书撤销列表格式增加了一些可选扩展，在概念上与证书扩展相似。ＣＡｓ应能产生如下的Ｘ． ５０９ ｖ２ ＣＲＬｓ，当验证证书认证路径时客户也应能处理它们。颁发ＣＲＬｓ的ＣＡ不一定必须是颁发该撤销证书的ＣＡ。一些ＣＡｓ只负责发放ＣＲＬｓ ｏ Ｘ． ５０９ ｖ２ ＣＲＩ、包含以下信息：Ｖｅｒｓｉ ｏｎ版本； Ｉｓｓｕｅｒ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ颁发者签名算法；Ｉ ｓｓｕｅｒ Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ颁发者可辨别名；Ｔｈｉ ｓ Ｕｐｄａｔｅ本次更新；ＧＢ／Ｔ １９７７１－２００５Ｎｅ ｘｔ Ｕｐｄａｔｅ下次更新；Ｒｅｖｏｋｅｄ Ｃｅｒｔｉｆｉｃａｔｅｓ撤销的证书，零个或多个以下序列的序列： 令 Ｃｅｒｔｉｆｉｃａｔｅ Ｓｅｒｉａｌ Ｎｕｍｂｅｒ证书序列号，今Ｒｅｖｏｃａｔ ｉｏｎ Ｄａｔｅ撤销日期，令ＣＲＬ Ｅｎｔｒｙ Ｅｘｔｅｎｓｉｏｎｓ ＣＲＴ． Ｅｎｔｒｙ扩展（可选）；ＣＲＬ Ｅｘｔｅｎｓｉｏｎｓ ＣＲＴ，扩展（可选）；颁发者对以上字段的签名。 ６． ３． ２ ＣＲＬ字段Ｘ． ５０９ ｖ２ ＣＲＴ．的ＡＳＮ． １句法见附录Ａ。对于签名计算，签名的输人数据是ＡＳＮ． Ｉ ＤＥＲ形式的编码。ＡＳＮ． １ ＤＥＲ编码对每一个元素来说都是标签、长度、值的编码系统。以下各项描述了Ｘ． ５０９ ｖ２ＣＲＬ的使用：ａ） Ｖｅｒｓｉｏｎ这个字段描述了编码后的ＣＲＴ ，的版本。该字段的值应是Ｉ，表明是ｖ２ ＣＲＬ。ｂ） Ｓｉｇｎａｔｕｒｅ该字段包含签署ＣＲＬ的算法的算法标识符。它的内容与证书的ｓｉ ｇｎａｔｕｒｅ字段一样。关于这个字段的信息见６．２．１中关于ｓ ｉｇｎａｔｕｒｅ字段的定义。ＣＲＴ，可以被６． ２． ２． ２中标识的任何算法签名； 通常，ＣＡ使用同一算法来对证书和ＣＲＴ、签名。ｃ） Ｉｓｓｕｅｒ Ｎａｍｅ ｉｓｓｕｅｒ字段提供了签署ＣＲＴ，的ＣＡ的全球唯一标识名。颁发者的名字是Ｘ． ５００可辨别名。本标准不支持ＣＲＴ．颁发者名字为空的ＣＲＬ ｏｄ） Ｔｈｉｓ Ｕｐｄａｔｅｔｈｉ ｓＵｐｄａｔｅ字段指定了该ＣＲＬ的日期。此字段可以是ＵＴＣＴｉｍｅ或ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅ。对于本标准， ｔｈｉｓＵｐｄａｔｅ字段遵从证书的ｖａｌｉｄｉｔｙ字段的规则。（见６．２．１）ｅ） Ｎｅｘｔ Ｕｐｄａｔｅｎｅｘｔ Ｕｐｄａｔｅ字段指定了下一个ＣＲＬ颁发的日期。下一个ＣＲＬ颁发的日期可以在指定日期 之前，但不可在指定日期之后。此字段可以是ＵＴＣＴｉｍｅ或ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅ。对于本标准，ｎｅｘｔ Ｕｐｄａｔｅ字段遵从证书的ｖａｌｉｄｉｔｙ字段的规则。（见６．２． １）ｆ） Ｒｅｖｏｋｅｄ Ｃｅｒｔｉｆｉｃａｔｅｓｒ ｅｖｏｋｅｄＣｅｒｔｉｆｉｃａｔｅｓ字段是一个已经被撤销的证书的列表。每个被撤销证书包含：１）证书序列号（在ｕｓｅｒＣｅｒｔｉ ｆｉｃａｔｅ字段中指出）。它包含被撤销证书的ｓｅｒｉａｌＮｕｍｂｅｒ字段的 值。它必须与颁发ＣＡ的名字一起使用以识别一个已经被撤销但还未到期的证书。２）包含撤销日期的ｒ ｅｖｏｃａｔｉｏｎＤａｔｅ字段。本字段取值遵从证书的ｖａｌｉｄｉｔｙ字段的规则。（见６． ２． １）３） ＣＲＬ Ｅｎｔｒｙ扩展（可选）（见６． ３． ４ ）。它可以给出证书撤销的原因，说明证书无效日期，也可以说明发放该被撤销证书的ＣＡ的名字（或许与颁发ＣＲＬ的ＣＡ不是同一个）。注意： 我们假定颁发ＣＲＩ ＿的ＣＡ和颁发被撤销证书的ＣＡ是同一个，除非ＣＲＩ． Ｅｎｔｒｙ扩展包含ｃｅｒｔｉ ｆｉｃａｔｅｌｓｓｕｅｒ字段。６． ３． ３ ＣＲＬ扩展１ ＳＯ／ＩＴＵ所定义的Ｘ． ５０９ ｖ２ ＣＲＬｓ扩展提供了对全部ＣＲＬｓ附加其他信息的方法。每个ＣＲＬ扩展被设计为ｃｒｉｔｉｃａｌ或ｎｏｎｃｒｉｔｉｃａｌ．（关键的或非关键的）如果客户碰到一个不能处理的关键性扩展，将无法对该ＣＲＬ进行验证。本条描述了应被支持的ＣＲＩ ．扩展。当ＣＡ能够产生一个ＣＲＬ的扩展且客户能够处理该扩展时，此ＣＲＩ＿扩展才有效。ＧＢ／Ｔ １９７７１－２００５ａ）机构密钥标识符 ａｕｔｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒ，非关键性ＣＲＩ，扩展，标识了ＣＡ用来签署ＣＲＩ，的密钥。当ＣＡ使用多个密钥时该扩展是有用的；它使得不同的密钥得以区分（例如，密钥更新时）。身份的鉴定可 基于密钥标识符或发放者名字和序列号。所有的ＣＲＩ．ｓ都应有密钥标识名。当发放者拥有多个签名密钥时（或多个密钥对，或是在密钥更新期间），该扩展是很有用的。当发放ＣＡ有多个 签名密钥对时，在所有的ＣＲＩ，扩展里都应包括该扩展，并且客户也应能够找到并验证ＣＲＩ ，验证路径。客户如果要查找证书认证路径， 必须能够处理ａｕｔｈｏｒｉｔｙＫｅｙｌｄｅｎｔｉｆｉｅ：的密钥标识符 或证书发放者名加上序列号。ｂ）颁发者别名 ｉｓｓｕｅｒＡｌｔＮａｍｅ，非关键性ＣＲＩ，扩展字段，包含一个或多个ＣＡ别名。别名一旦出现就放置在ｉ ｓｓｕｅｓｒＡｌｔＮａｍｅ里。并非所有的别名格式都要被识别处理，识别不出的别名格式可以被忽略。ＣＡ可在ＣＲＬｓ中产生该扩展，然而客户可以不予处理。 ｃ） ＣＲＬ编号ｃＲＬＮｕｍｂｅｒ，非关键性扩展字段，是一个单调增加的序列号， 该ＣＲＩ，由ＣＡ通过特定的ＣＡ目 录人口或ＣＲＬ分布点发放。该扩展可以用来通知证书使用者整个ＣＲＬ的非固定时间发布，或是便于确定何时某一ＣＲＬ替代了另一ＣＲＩ，。在ＣＲＬ中应该包括该扩展。 ｄ）颁发分布点ｉ ｓｓｕｉｎｇＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段是非关键性的扩展，决定了一个特定ＣＲＩ，的ＣＲＬ分布点。一个分布点就是一个用来检索ＣＲＩ ，的目录入口，它可以与ＣＡ的目录人口不同。ＣＡ要用密钥对ＣＲＩ ，加密。ＣＲ工Ｊ分布点没有自己的密钥对。另外，ｉ ｓｓｕｉｎｇＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段指定的ＣＲＬｓ可能只针对终端实体的证书，或者只针对ＣＡ证书， 或者只针对由于某种特定原因撤销的证书。最后，该扩展也可以确定一个间接ＣＲＬ，间接ＣＲＩ 一是由与发放被撤销证书ＣＡ不同的ＣＡ发放的。间接ＣＲＩ，包含以下组件：ｄｉ ｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ，给出了分布点的名字，遵循Ｘ． ５００标识名规则；ｏｎｌ ｙＣｏｎｔａｉｎｓＵｓｅｒＣｅｒｔｓ，布尔变量，表明该ＣＲＩ，只包含终端实体证书；ｏｎｌ ｙＣｏｎｔａｉｎｓＣＡＣｅｒｔｓ，布尔变量，表明该ＣＲＩ、只包含ＣＡ证书；ｏｎｌ ｙＳｏｍｅＲｅａｓｏｎｓ，一个ＲｅａｓｏｎＦｌａｇ位串，标明ＣＲＬ中所列证书的撤销原因；如下：．ｋｅ ｙＣｏｍｐｒｏｍｉｓｅ，表明密钥泄漏或怀疑密钥泄漏，．ｃＡＣｏｍｐｒｏｍｉ ｓｅ，表明该证书撤销的原因是ＣＡ密钥泄漏，它只用于撤销ＣＡ证书，．ａｆ ｆｉｌｉａｔｉｏｎＣｈａｎｇｅｄ，表明该证书撤销的原因是证书主体的从属关系改变了，令ｓｕｐｅｒｓｅｄｅｄ，表明该证书已被代替， 令ｃ ｅｒｔｉｆｉｃａｔｅＨｏｌｄ，表明证书处于冻结状态，可能会被撤销，．ｃ ｅｓｓａｔｉｏｎＯｆＯｐｅｒａｔｉｏｎ，表明该证书的目的已经不再被需要，但并不是密钥被泄漏； ＩｎｄｌｒｅｃｔＣＲＩ．，布尔变量，表明这是一个间接ＣＲＬ．客户应能处理这个字段。 ｅ）增量ＣＲＩ，指示符ｄｅ ｌｔａＣＲＬＩｎｄｉｃａｔｏ：是一个关键ＣＲＩ扩展，它确定一个增量ＣＲＩ，。对于那些采用非ＣＲＬ结构存储撤销信息的用户程序来说，增量ＣＲＩ可以有效地节省处理时间。它允许把变化的信息增 加到本地数据库里，忽略掉那些本地数据库中已经存在的未改变的信息部分。ＢａｓｅＣＲＬＮｕｍｂｅｒ的值表明基础ＣＲＩ的ＣＲＩ，序列号，基础ＣＲＩ 、是生成增量ＣＲＩ，的开始点。 增量ＣＲＩ，包含基础ＣＲＩ，和当前ＣＲＩ，之间的变化部分。是否提供增量ＣＲＬ要由ＣＡ来决定。 客户可以利用本地ＣＲＩ ，和增量ＣＲＩ合成一个ＣＲＩ．，要注意的是如果本地ＣＲＩ，的ＣＲＩ、序列ＧＢＪＴ １９７７１－２００５号小于增量ＣＲＩ．中的ＢａｓｅＣＲＬＮｕｍｂｅｒ，合成的ＣＲＩ ．就不正确。如果增量ＣＲＬ含有一个 ＣＲＬ序号扩展，那么合成的ＣＲＬ的ＣＲＩ．序号就是该扩展的值。客户和ＣＡ是否支持增量ＣＲＬ是可选的。 ｆ ） ＣＲＬ扩展使用总结表１总结了标准ＣＲＬ扩展，表２总结了这些标准ＣＲＩ ．扩展的使用。表１ ＣＲＬ扩展概要希爪月表２ ＣＲＬ扩展在本标准中的使用６． ３． ４ ＣＲＬ Ｅｎｔｒｙ扩展Ｘ． ５０９ ｖ２ ＣＲＬｓ所定义的Ｅｎｔｒｙ扩展提供了获取ＣＲＩ．每条附加信息的方法。每个ＣＲＬ Ｅｎｔｒｙ扩展被设计为关键性或非关键性。如果不能处理关键性扩展，该ＣＲＬ的验证将是无效的。如果是不可识别的非关键性ＣＲＬ Ｅｎｔｒｙ扩展，则可以忽略。ａ）原因代码 ｒｅａｓｏｎＣｏｄｅ是非关键性ＣＲＬ Ｅｎｔｒｙ扩展，标明了证书撤销原因。ＣＡ应当能够生成该扩展，但客户是否要处理ｒｅａｓｏｎＣｏｄｅ扩展则是可选的。下面列举的是ｒｅａｓｏｎＣｏｄｅ的取值： ＡＫｃＣＤＩｓｅＲｕｒｌｙｔＬｉＳｈａＮｎｄｏｇ： ＤｍＸ－ｅ｝ＩｆｒｂｓＫｔ；ｉＣｈｕａｄＲＡｙｌｃＬ．＃ｅ１＊｀ｒｏｎＭ ｔｉＰＡｆ，．＂Ｃ｝Ｒ１Ｌ亡 川 ｕｎｓｐｅｃｉｆｉｅｄ，未使用；ｋｅ ｙＣｏｍｐｒｏｍｉｓｅ，表明密钥泄漏或怀疑泄漏；ｃＡＣｏｍｐｒｏｍｉ ｓｅ，表明该证书撤销的原因是ＣＡ密钥泄漏，它只用于撤销ＣＡ证书；ＧＢ／Ｔ １９７７１－２００５ ａｆｆｉｌｉａｔｉｏｎＣｈａｎｇｅｄ，表明该证书撤销的原因是证书主体的从属关系改变了；ｓｕｐｅ ｒｓｅｄｅｄ，表明该证书已被新的证书代替； ｃｅｓｓａｔｉｏｎＯｆＯｐｅｒａｔｉｏｎ，表明该证书的功能已经不需要，并不是密钥泄漏；ｃｅｒｔｉ ｆｉｃａｔｅＨｏｌｄ，表明证书当前不能使用，如果证书的ＣＲＬ的ｒｅａｓｏｎＣｏｄｅ字段是ｃｅｒｔｉｆｉ－ ｃａｔｅＨｏｌｄ，那么客户就无法验证证书认证路径；ｒ ｅｍｏｖｅＦｒｏｍＣＲＬ，只与增量ＣＲＩ．一块使用，表明应该删除一个存在的ＣＲＬＥｎｔｒｙｏｂ）过期日期 ｅｘｐｉ ｒａｔｉｏｎＤａｔｅ，非关键性ＣＲＩ． Ｅｎｔｒｙ扩展，表明Ｅｎｔｒｙ的过期时间。该扩展不在ＣＲＬｓ中使 用，也不被客户使用。ｃ）指令码 ｉｎｓｔｒｕｃｔｉｏｎＣｏｄｅ是非关键性ＣＲＬ Ｅｎｔｒｙ扩展，提供了一个注册过的指令标识符，指令标识符来指出当遇到一个被冻结的证书时要采取何种操作。本扩展不在ＣＲＬ中使用。 ｄ）无效日期ｉ ｎｖａｌｉｄｉｔｙＤａｔｅ是非关键性ＣＲＬ Ｅｎｔｒｙ扩展，指出知道密钥泄漏或怀疑泄漏的日期，即证书无效的日期。该日期必须比ＣＲＩ ， Ｅｎｔｒｙ中的撤销日期要早。而ＣＲＬ Ｅｎｔｒｙ中的撤销日期表明的是ＣＡ撤销证书的日期。无论是否可以获得此信息，都应该鼓励ＣＡｓ将此信息与ＣＲＬ用 户共享。ＣＡｓ在ＣＲＬｓ中生成该扩展，取值的形式是Ｇｅｎｅｒａｌ ｉｚｅｄＴｉｍｅｏｅ）证书发放者 ｃｅｒｔｉｆｉｃａｔｅｌｓｓｕｅｒ和间接ＣＲＬ一起使用，（间接ＣＲＩ，，是ｉｓｓｕｉｎｇＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ扩展中有ｉｎ－ｄｉ ｒｅｃｔＣＲＬ标识符的ＣＲＬ）。如果该扩展没有在间接ＣＲＩ，的第一个Ｅｎｔｒｙ中标出，那么该证书的发放者默认为ＣＲＬ发放者。在间接ＣＲＬ随后的Ｅｎｔ ｒｙ里，如果没有给出ｃｅｒｔｉｆｉｃａｔｅｌｓｓｕ－ｅｒ， 则认为证书发放者与前一个ＣＲＩ． Ｅｎｔｒｙ的发放者相同。ｆ） ＣＲＬ Ｅｎｔｒｙ扩展使用总结表３总结了ＣＲＬ Ｅｎｔｒｙ扩展，表４总结了本标准中ＣＲＬ Ｅｎｔｒｙ扩展的使用。表３ ＣＲＬ Ｅｎｔｒｙ扩展阵耸万日月表４本标准中ＣＲＬ Ｅｎｔｒｙ扩展的使用６．４证书认证路径一公亡－ｎ ７ＣＺＡＲｉ ｐＬ－．＇＂Ｊ｝Ｕｎ．Ｗ！ＭＴ１ＸＦ＊｝ ＇４３ＡＩＰＴＥ１｝４，３Ｏ＂ＬｊＣｋＩ１｝Ｒ＃Ｊ７４．％Ｖ＂ＵｉＸｔＦＯ７２＊Ｊ，Ｉ／９Ｐｐｆｒｈ｝ ＲＦＣ ２４５９中的第６章有具体定义，认证路径功能应由客户来实现。ＧＢ／Ｔ １９７７１－２００５６．５事务消息格式６．５．１事务消息格式概述本条给出了一套最小的支持ＰＫＩ事务的消息格式。系统如果想实现这些事务就必须支持这些消 息格式，并能够正确的产生、识别它们。这些消息格式以ＡＳＮ． １的形式定义；消息利用ＤＥＲ编码传输。６．５．２全体ＰＫＩ消息组件ａ） ＰＫＩ消息每个消息有四个组件： ＰＫＩ Ｍｅｓｓａｇｅ：：＝ＳＥＱＵＥＮＣＥ｛ｈｅａｄｅｒ ＰＫＩＨｅａｄｅｒ， ｂｏｄｙ ＰＫＩＢｏｄｙ，ｐｒｏｔｅｃｔ ｉｏｎ ［０］ ＰＫＩＰｒｏｔｅｃｔｉｏｎ ＯＰＴＩＯＮＡＬ，ｅｘｔ ｒａＣｅｒｔｓ ［１］ ＳＥＱＵＥＮＣＥ ＯＦ Ｃｅｒｔｉｆｉｃａｔｅ ＯＰＴＩＯＮＡＬ｝ｅｘｔ ｒａＣｅｒｔｓ字段在本标准中用来放签名的证书序列，后面消息的描述中对这个字段不再具体描述。 ｂ） ＰＫＩ消息头所有的ＰＫＩ消息都需要头信息来识别地址和处理。一些头信息会在传输特定包里给出。然 而， 如果ＰＫＩ消息被签名，这个头信息也是被保护的。 下面是消息头的数据结构：ＰＫＩＨｅａｄｅｒ：：＝ＳＥＱＵＥＮＣＥ｛ ｐｖｎｏ ＩＮＴＥＧＥＲｓｅｎｄｅｒ ＧｅｎｅｒａｌＮａｍｅ，｛ｉｅｔｆ－ｖｅｒｓｉｏｎ２（１）｝，一标识发送者ｒ ｅｃｉｐｉｅｎｔ ＧｅｎｅｒａｌＮａｍｅ， 一该消息的产生时间（发送者使用）一该时间对接收者来说仍然有意义。 一标识接收者ｍｅ ｓｓａｇｅＴｉｍｅ ［０］ ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅ ＯＰＴＩＯＮＡＬ，ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ ［１］ Ａｌｇｏｒｉｔｈｍｌｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，一计算保护比特的算法 ｓ ｅｎｄｅｒＫＩＤ ［２］ ＫｅｙＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ．， ｒｅｃｉｐＫＩＤ ［３］ ＫｅｙＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，一确定用来保护的特定密钥 ｔ ｒａｎｓａｃｔｉｏｎＩＤ ［４］ ＯＣＴＥＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ，一确定事务，也就是说， 相应的请求、响应和确认消息的ｔｒａｎｓａｃｔｉｏｎｌＤ相同。ｓｅｎｄｅｒＮｏｎｃｅ ［５］ ＯＣＴＥＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ， ｒｅｃｉｐＮｏｎｃｅ ［６］ ＯＣＴＥＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ，一ｎｏｎｃｅｓ用来提供重发保护，消息的产生者插人ｓｅｎｄｅｒＮｏｎｃｅ；该消息的接收者在相 一应消息中插入ｒ ｅｃｉｐＮｏｎｃｅ ｏｆｒｅｅＴｅｘｔ ［７］ ＰＫＩＦｒｅｅＴｅｘｔ ＯＰＴＩＯＮＡＬ，一这可以用来进行一些上下文说明（本字段的设计便于人工阅读） ｇｅ ｎｅｒａｌＩｎｆｏ仁８］ ＳＥＱＵＥＮＣＥ ＳＩＺＥ（１二ＭＡＸ） ＯＦ ＩｎｆｏＴｙｐｅＡｎｄＶａｌｕｅ ＯＰＴＩＯＮＡＬ 一用来传递上下文相关信息一（本字段不是主要为人工考虑的）｝ ＰＫＩＦｒｅｅＴｅｘｔ：：＝ＵＴＦ８Ｓｔｒｉ ｎｇＧＢ／Ｔ １９７７１－２００５头消息中的ｔ ｒａｎｓａｃｔｉｏｎＩＤ字段允许响应消息的接收者将它与请求相关联。一个ＲＡ或许在同一个时刻有很多请求未被处理。为了做到有效，从发送者的角度看，本字段的取值应当是 独一无二的。 ＭｅｓｓａｇｅＴｉ ｍｅ字段表明消息产生的时间。它的值必须是格林威治时间，必须精确到秒（即年月日时分秒ＹＹＹＹＭＭＤＤＨＨＭＭＳＳＺ），即使秒是零。ＭｅｓｓａｇｅＴｉ ｍｅ字段不包括分秒。 ｓｅｎｄｅｒ和ｒｅｃｉｐｉｅｎｔ字段定义为ＧｅｎｅｒａｌＮａｍｅ。系统必须支持Ｘ． ５００标识名和ＲＦＣ ８２２ （Ｉｎ－ｔ ｅｒｎｅｔ ｅ－ｍａｉｌ）标识名。ｆ ｒｅｅｔｅｘｔ字段定义为ＰＫＩＦｒｅｅ Ｔｅｘｔ， ＰＫＩＦｒｅｅ Ｔｅｘｔ是ＡＳＮ． １中的ＵＴＦ８Ｓｔｒｉｎｇ型。 ＵＴＦ８Ｓｔｒｉｎｇ是统一字符集，它包括了ＡＳＣＩＩ，本标准中，ＰＫＩＦｒｅｅ Ｔｅｘｔ仅包括ＡＳＣＩＩ中的字符。 ＰｒｏｔｅｃｔｉｏｎＡｌｇ所有的签名消息，以及用消息认证码保护的消息都要有该字段。当一个消息不受保护时（即，在含有ＰＫＩ Ｈｅａｄｅｒ的ＰＫＩＭｅｓｓａｇｅ中不出现ｐｒｏｔｅｃｔｉｏｎ字段时），Ｐｒｏｔｅｃｔｉｏｎ－Ａｌ ｇ必须被忽略。 ｓｅｎｄｅｒＮｏｎｃｅ和ｒｅｃｉｐＮｏｎｃｅ在。ｌｉｅｎｔ和ＲＡ中是不需要的；ＣＡ如果收到了带有ｓｅｎｄｅｒＮｏｎｃｅ的ＰＫＩ Ｍｅｓｓａｇｅ，就必须在随后的消息里返回ｒｅｃｉｐＮｏｎｃｅ。本标准中，ｓｅｎｄｅｒＫＩＤ， ｒｅｃｉｐＫＩＤ，ｇｅｎｅ ｒａｌＩｎｆｏ是不需要的。ｃ） ＰＫＩ消息正文ＰＫＩＢｏｄｙ：：＝ＣＨＯＩＣＥ｛ 一ｍｅｓｓａｇｅ－ｓｐｅｃｉ ｆｉｃ ｂｏｄｙ ｅｌｅｍｅｎｔｓｃｒ ［２］ ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ，一证书请求 ｃｐ ［３］ ＣｅｒｔＲｅｐＭｅｓｓａｇｅ，一证书响应ｐ１０ｃｒ ［４］ ＰＫＣＳ１０ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ，一引自［ＰＫＣＳ１０］ｒ ｒ ［１１］ ＲｅｖＲｅｇＣｏｎｔｅｎｔ，ｒｐ ［１２］ ＲｅｖＲｅｐＣｏｎｔｅｎｔ，一撤销请求一撤销响应 ｃｏｎｆ ［１９］ ＰＫＩＣｏｎｆｉｒｍＣｏｎｔｅｎｔ，一确认｝其他的ｍｅ ｓｓａｇｅ－ｓｐｅｃｉｆｉｃ正文元素在ＲＦＣ２５１０， ＲＦＣ２５１１中定义。本标准并不需要这些元素，所以这里把它们省略了。附录Ｃ中描述了ｍｅｓｓａｇｅ－ｓｐｅｃｉ ｆｉｃ正文元素的完整列表。其他部分所说的Ｃｅｒ ｔＲｅｑ， ＣｅｒｔＲｅｐ， ＲｅｖＲｅｑ， ＲｅｖＲｅｐ在ＰＫＩＭｅｓｓａｇｅ里就是指ｉｒ，ｉｐ，ｃｒ，ｃｐ，ｒｒ， ｒｐ。一个ＰＫＣＳ ＃ １０请求是指带有ｐｌＯｃｒ正文元素的消息。一个确认消息带有正文消息ｃｏｎｆ ｏｄ） ＰＫＩ消息保护使用以下结构，所有ＰＫＩ消息的完整性将得到保护： ＰＫＩＰｒｏｔｅｃｔｉ ｏｎ：：＝ＢＩＴ ＳＴＲＩＮＧ用来计算ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ的输入是如下数据结构的ＤＥＲ编码：Ｐｒｏｔｅｃｔ ｅｄＰａｒｔ：：＝ＳＥＱＵＥＮＣＥｔＨｅａｄｅｒ ＰＫＩＨｅａｄｅｒ，ｂｏｄｙ ＰＫＩＢｏｄｙ｝在大多数情况下， ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段将包含一个数字签名，ＰＫＩＨｅａｄｅｒ里的ｐｒｏｔｅｃｔｉｏｎＡｌｇ字段将包含一个Ａｌ ｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ，用来说明为保护消息所使用的数字签名算法。在有些情况下，例如密钥更新，附加多重签名是必要的。这时，签名消息是嵌套的结构一每个 已签名的消息成为一个ＰＫＩ Ｂｏｄｙ的元素；下一个签名应用于这个消息。这个处理将会不断重复直到所有的签名都已应用完毕。 ＧＢ／Ｔ １９７７１－２００５６．５．３通用数据结构下面的数据类型对几个消息格式都是通用的。 ａ）证书模板在各种各样的ＰＫＩ管理消息中，始发者可能会提供一些值来识别一个已存在的证书，或申请 一个证书时在请求中含有一些值。Ｃｅ ｒｔＴｅｍｐｌａｔｅ结构允许实体标明这些值。ＣｅｒｔＴｅｍｐｌａｔｅ包含作为一个证书所需的所有信息。 ＣｅｒｔＴｅｍｐｌａｔｅ：：＝ＳＥＱＵＥＮＣＥ｛ｖｅｒｓｉ ｏｎ ［０］ Ｖｅｒｓｉｏｎ ＯＰＴＩＯＮＡＬ， 一用来请求特殊语法版本ｓｅｒｉ ａｌ ［１］ ＩＮＴＥＧＥＲ ＯＰＴＩＯＮＡＬ，一用来请求一个特殊的序列号或声明请求代表一个以前的证书持有者 ｓ ｉｇｎｉｎｇＡｌｇ ［２］ ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，ｓｕｂｊ ｅｃｔ ［３］ Ｎａｍｅ ＯＰＴＩＯＮＡＬ，ｖａｌ ｉｄｉｔｙ仁４］ ＯｐｔｉｏｎａｌＶａｌｉｄｉｔｙ ＯＰＴＩＯＮＡＬ，ｉ ｓｓｕｅｒ仁５］ Ｎａｍｅ ＯＰＴＩＯＮＡＬ，ｐｕｂｌ ｉｃＫｅｙ ［６］ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ ＯＰＴＩＯＮＡＬ， ｉｓｓｕｅｒＵＩＤ ［７］ ＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，一ｎｏｔ ｓｕｐｐｏｒｔｅｄｓ ｕｂｊｅｃｔＵＩＤ ［８］ ＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，一ｎｏｔ ｓｕｐｐｏｒｔｅｄｅｘｔｅｎｓｉ ｏｎｓ ［９］ Ｅｘｔｅｎｓｉｏｎｓ ＯＰＴＩＯＮＡＬ，一包含请求者希望在证书里具有的扩展 ｝ Ｏｐｔ ｉｏｎａｌＶａｌｉｄｉｔｙ：：＝ＳＥＱＵＥＮＣＥ｛ｎｏｔＢｅｆ ｏｒｅ ［０］ Ｔｉｍｅ ＯＰＴＩＯＮＡＬ，ｎｏｔＡｆ ｔｅｒ ［１］ Ｔｉｍｅ ＯＰＴＩＯＮＡＬ｝ ＣｅｒｔＴｅｍｐｌａｔｅｓ：：＝ＳＥＱＵＥＮＣＥ ＯＦ ＣｅｒｔＴｅｍｐｌａｔｅ如果ＣｅｒｔＴｅｍｐｌ ａｔｅ出现，ｖａｌｉｄｉｔｙ字段将包含请求证书的请求发放日期（ｎｏｔｂｅｆｏｒｅ字段）和期满日期（ｎｏｔ Ａｆｔｅｒ）。对ＣｅｒｔＴｅｍｐｌａｔｅ中的ｖａｌｉｄｉｔｙ字段和证书中的ｖａｌｉｄｉｔｙ字段的解释相同。（见５．２．１） ｂ）签名私钥的拥有证明若由主体产生密钥对， ＣＡ需要验证证书请求中主体拥有对应于相应公钥的私钥。这是通过Ｐｒ ｏｏｆ０ｆＰｏｓｓｅｓｓｉｏｎ字段来实现的。 当用户申请一个签名证书，则用Ｐｒｏｏｆ ＯｆＰｏｓｓｅｓｓｉｏｎ中的ｓｉｇｎａｔｕｒｅ字段实现的，该ｓｉｇｎａｔｕｒｅ是一个ＰＯＰＯＳｉ ｇｎｉｎｇＫｅｙ结构。该结构包含输入数据、一个算法标识符和一个签名。输入数据作为ＤＥＲ编码的ｐｏｐＩ ｎｐｕｔ，它是由证书请求中的数据生成的。通常，它包含Ｃｅｒｔ－Ｔｅｍｐｌ ａｔｅ里的主体名和公钥。当一个新的主体请求通过公钥ｍａｃ验证后，或是ＲＡ修改了主体名后， ｐｏｐＩｎｐｕｔ必须由ＰＯＰＯＳｉｇｎｉｎｇＫｅｙ结构中的可选数据和ＣｅｒｔＴｅｍｐｌａｔｅ里的公钥构成。这就允许ＲＡ把拥有证明传递给ＣＡ而不用改变Ｃｅｒ ｔＴｅｍｐｌａｔｅ ｏＰｒｏｏｆＯｆＰｏｓｓｅｓｓｉ ｏｎ：：＝ＣＨＯＩＣＥ｛ｒａＶｅｒｉ ｆｉｅｄ ［０］ ＮＵＬＬ， 一当ＲＡ已经验证了请求者拥有相应私钥时使用ｓ ｉｇｎａｔｕｌｅ ［１］ ＰＯＰＯＳｉｇｎｉｎｇＫｅｙ，一用户产生证书密钥对，并申请签名证书时使用 ＧＢ／Ｔ １９７７１－２００５ｋｅ ｙＥｎｃｉｐｈｅｒｍｅｎｔ一本标准不使用该域 仁２］ ＰＯＰＯＰｒｉｖＫｅｙ， ｋｅｙＡｇｒｅｅｍｅｎｔ ［３］ ＰＯＰＯＰｒｉｖＫｅｙ一本标准不使用该域｝ ＰＯＰＯＳｉ ｇｎｉｎｇＫｅｙ：：＝ＳＥＱＵＥＮＣＥ｛ ｐｏｐｏｓｋＩｎｐｕｔ ［０］ ＰＯＰＯＳＫＩｎｐｕｔ ＯＰＴＩＯＮＡＬ，ａｌ ｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ，ｓｉ ｇｎａｔｕｒｅ ＢＩＴ ＳＴＲＩＮＧ｝一对ｐｏｐＩｎｐｕｔ的ＤＥＲ编码值签名（用”ａｌ ｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ＂ ）一注意：如果在ＰＯＰ字段里出现ｐｏｐｏｓｋＩ ｎｐｕｔ， ｐｏｐＩｎｐｕｔ就由ｏｔｈｅｒｉｎｐｕｔ构成。一如果ｐｏｐｏｓｋＩｎｐｕｔ没有出现，主体就是ＣｅｒｔＴｅｍｐｌ ａｔｅ中的名字。一注意ＰｏｐＩ ｎｐｕｔ的编码值是有意含糊的。 ＰｏｐｏｓｋＩｎｐｕｔ：：＝ＣＨＯＩＣＥ｛Ｓｕｂｊｅｃｔ ｎａｍｅ，Ｓｅｎｄｅｒ ［０］ ｇｅｎｅｒａｌＮａｍｅ， ｐｕｂｌｉｃＫｅｙＭＡＣ仁１］ ＰＫＭＡＣＶａｌｕｅ｝一ｐｏｐ的计算是基于ｐｏｐＩ ｎｐｕｔ的结构的。ＰｏｐＩｎｐｕｔ的结构定义如下：ＰｏｐＩ ｎｐｕｔ：：＝ＳＥＱＵＥＮＣＥ｛ＣＨＯＩ ＣＥ｛ ｏｔｈｅｒｉｎｐｕｔ ｐｏｐｓｋＩｎｐｕｔ，ｓｕｂｊｅｃｔ ｎａｍｅ｝，ｐｕｂｌ ｉｃＫｅｙ ｓｕｂｊｅｃｔｐｕｂｌｉｃＫｅｙ）一如果ｐｏｐｏｓ ｋＩｎｐｕｔ在ＰＯＰ字段出现的话，ｐｏｐＩｎｐｕｔ就用ｏｔｈｅｒｉｎｐｕ构成。如果ｐｏｐｏｓｋＩｎｐｕｔ不出现，主体就是ＣｅｒｔＴｅｍｐｌ ａｔｅ中的名字。一注意ＰｏｐＩ ｎｐｕｔ的编码值是有意含糊的。ｃ）证书请求消息ＣｅｒｔＲｅｇＭｓｇ是证书请求的基本结构。ＣｅｒｔＲｅｇＭｓｇ由三个字段构成的ＳＥＱＵＥＮＣＥ，ｃｅｒ－ ｔ Ｒｅｑ； ｐｏｐ； ｒｅｇＩｎｆｏ（可选）ｏ ｃｅｒｔＲｅｑ是类型ＣｅｒｔＲｅｑｕｅｓｔ， ｐｏｐ包括了证明拥有私钥的信息， ｒｅｇＩｎｆｏ包含了特定的注册过程信息。ｒｅｇＩｎｆｏ字段是可选的。ＣｅｒｔＲｅｇＭｓｇ定义见附录Ｄ｝ＣｅｒｔＲｅｇＭｓｇ：：＝ＳＥＱＵＥＮＣＥ｛ ｃｅｒｔ Ｒｅｑ ＣｅｒｔＲｅｑｕｅｓｔ，ＰＯＰ Ｐｒｏｏｆ０ｆＰｏｓｓｅｓｓｉｏｎ ＯＰＴＩＯＮＡＬ， 一本标准规定加密密钥对必须集中产生，此时该字段不出现一若集中产生签名密钥对，则该字段不出现 一若是由终端实体产生签名密钥对，则该字段必须出现 ｒｅｇｌｎｆｏ ＳＥＱＵＥＮＣＥ ＳＩＺＥＤ二ＭＡＸ） ｏｆ ＡｔｔｒｉｂｕｔｅＴｙｐｅＡｎｄＶａｌｕｅ ＯＰＴＩＯＮＡＬ｝Ｃｅｒｔ ＲｅｑｕｅｓｔＣｅｒ ｔＲｅｑｕｅｓｔ的组成包括：请求标识符，证书模板，可选的控制信息。Ｃｅｒｔ Ｒｅｑｕｅｓｔ：：＝ＳＥＱＵＥＮＣＥ｛ ｃｅｒｔＲｅｇＩｄ ＩＮＴＥＧＥＲ，ｃｅ ｒｔＴｅｍｐｌａｔｅ ＣｅｒｔＴｅｍｐｌａｔｅ，一用来匹配请求和相应的ＩＤ一选定的证书中的某些字段ｃｏｎｔｒｏｌ ｓ Ｃｏｎｔｒｏｌｓ ＯＰＴＩＯＮＡＬ｝一控制颁发的一些属性ｃ ｅｒｔＲｅｇＩｄ是一个ＩＮＴＥＧＥＲ， ｃｅｒｔＴｅｍｐｌａｔｅ是ＣｅｒｔＴｅｍｐｌａｔｅ， ｃｏｎｔｒｏｌｓ的定义如下。ＧＢ／Ｔ １９７７１－２００５Ｃｅｒｔ ＲｅｇＭｅｓｓａｇｅｓＣｅ ｒｔＲｅｇＭｅｓｓａｇｅｓ是一个或多个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ序３ｉｌ的结构。Ｃｅｒｔ ＲｅｇＭｅｓｓａｇｅｓ：：一ＳＥＱＵＥＮＣＥ ＳＩＺＥ（１．．ＭＡＸ） ＯＦ ＣｅｒｔＲｅｇＭｅｓｓａｇｅ本标准中， ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ可以假设为仅由一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ构成的ＳＥＱＵＥＮＣＥ。即ＭＡＸ可以定义为ｌａ Ｃｏｎｔ ｒｏｌｓＣｅｒ ｔＲｅｑｕｅｓｔ的产生者可以包括一个或多个适合请求处理的ｃｏｎｔｒｏｌ值。Ｃｏｎｔ ｒｏｌｓ：：＝ＳＥＱＵＥＮＣＥ ＳＩＺＥ（１二ＭＡＸ） ＯＦ ＡｔｔｒｉｂｕｔｅＴｙｐｅＡｎｄＶａｌｕｅ下列。ｏｎｔ ｒｏｌ在证书管理协议（ＣＭＰ）里有定义：ｒｅｇＴｏｋｅｎ； ａｕｔｈｅｎｔｉｃａｔｏｒ； ｐｋｉＰｕｂｌｉｃａｔｉｏｎｌｎ－ｆ ｏ； ｐｋｉＡｒｃｈｉｖｅＯｐｔｉｏｎｓ； ｏｌｄＣｅｒｔＩｄ； ｐｒｏｔｏｃｏｌＥｎｃｒＫｅｙ。在具体实现规范中的事务时，这些ｃｏｎ－ ｔｒｏｌ是可选的。这些ｃｏｎｔｒｏｌ的ＯＩＤｓ如下。本标准不需要的ｃｏｎｔｒｏｌ （ｏｌｄＣｅｒｔＩｄ， ｒｅｇＴｏｋｅｎ，ａｕｔ ｈｅｎｔｉｃａｔｏｒ， ｐｋｉＰｕｂｌｉｃａｔｉｏｎｌｎｆｏ， ａｎｄ ｐｋｉＡｒｃｈｉｖｅＯｐｔｉｏｎｓ）在这里没有描述。ｉ ｄ－ｐｋｉｘ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉｓｏ（Ｉ）ｉｄｅｎｔｉｆｉｅｄ－ｏｒｇａｎｉｚａｔｉｏｎ（３）ｄｏｄ（６） ｉｎｔｅｒｎｅｔ（Ｉ）ｓｅｃｕｒｉｔｙ（５）ｍｅｃｈａｎｉｓｍｓ（５） ｐｋｉｘ（７）｝ 一ａｒｃ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｘ． ５０９ ＰＫＩ ｐｒｏｔｏｃｏｌｓ ａｎｄ ｔｈｅｉｒ ｃｏｍｐｏｎｅｎｔｓｉ ｄ－ｐｋｉｐ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：｛ｉｄ－ｐｋｉｘ ｐｋｉｐ（５）｝ 一Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃｏｎｔｒｏｌｓ ｉｎ ＣＲＭＦｉ ｄ－ｒｅｇＣｔｒｌ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉｄ－ｐｋｉｐ ｒｅｇＣｔｒｌ（１）｝ ｉｄ－ｒｅｇＣｔｒｌ－ｏｌｄＣｅｒｔＩｄ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｉｄ－ｒｅｇＣｔｒｌ ５｝ｉ ｄ－ｒｅｇＣｔｒｌ－ｐｒｏｔｏｃｏｌＥｎｃｒＫｅｙ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：“｛ｉｄ－ｒｅｇＣｔｒｌ ６｝ｄ）协议加密密钥控制 如果存在的话，协议加密密钥控制明确了ＣＡ用来对ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ的响应进行加密的密钥。 当ＣＡ发送给申请者的信息需要加密的时候就可以使用这一控制。这些信息包括ＣＡ把产生 的私钥发给申请者供其使用。 ｐｒｏｔｏｃｏｌＥｎｃｒＫｅｙ控制由属性类型里的ｉｄ－ｒｅｇ－ｐｒｏｔｏｃｏｌＥｎｃｒＫｅｙ的ＯＩＤ来确定。它的值的语法是Ｓｕｂ ｊｅｃｔＰｕｂｌｉｃＫｅｙｌｎｆｏ．ｅ） ＰＫＩ消息状态码所有的响应消息都包含一些状态信息。定义如下的取值： ＰＫＩ Ｓｔａｔｕｓ：：＝ＩＮＴＥＧＥＲ｛ ｇｒａｎｔｅｄ （０），一请求得到许可，没有变更 ｇｒａｎｔｅｄＷｉ ｔｈＭｏｄｓ（１），一请求得到许可，有变更；请求者负责确定变更。 ｒｅｊｅｃｔｉｏｎ （２），一请求被拒绝 ｗａｉｔｉｎｇ （３），一已收到请求但还未处理，处理后将会附加一个响应 ｒｅｖｏｃａｔ ｉｏｎＷａｒｎｉｎｇ （４），一给予警告：撤销已被请求，正在处理。 ｒｅｖｏｃａｔ ｉｏｎＮｏｔｉｆｉｃａｔｉｏｎ （５），一通知：已经撤销 ｋｅｙＵｐｄａｔ ｅＷａｒｎｉｎｇ （６）｝ＧＢ／Ｔ １９７７１－２００５本标准并未用到ＫｅｙＵｐｄａｔ ｅＷａｒｎｉｎｇ状态码。ｆ）失败信息响应者使用以下句法提供更多失败信息。 ＰＫＩＦａｉ ｌｕｒｅＩｎｆｏ ：： ＢＩＴ ＝ ＳＴＲＩＮＧ｛一因为会以多种方式失败！ｂａｄＡｌ ｇ （０），一不被识别或不被支持算法名ｂａｄＭｅｓｓａｇｅＣｈｅｃｋ （１），一完整性检查失败（例如，签名核对错误）ｂａｄＲｅｑｕｅｓｔ （２），一事务不被允许或支持 ｂａｄＴｉｍｅ （３），一ｍｅｓｓａｇｅＴｉｍｅ与系统时间相差太多ｂａｄＣｅ ｒｔｌｄ （４），一证书标识名错ｂａｄＤａｔ ａＦｏｒｍａｔ （５），一数据格式不对 ｗｒｏｎｇＡｕｔｈｏｒｉｔｙ （６），ｉ ｎｃｏｒｒｅｃｔＤａｔａ （７），一请求中指出的ａｕｔｈｏｒｉｔｙ和响应者不同一请求者的数据不对（在公证服务里用）ｍｉ ｓｓｉｎｇＴｉｍｅＳｔａｍｐ （８），一没有时戳，但是策略需要 ｂａｄＰｏＰ （９）一拥有证明字段核实失败，一需要更多的失败信息｝ ＰＫＩＳｔ ａｔｕｓＩｎｆｏ：：＝ＳＥＱＵＥＮＣＥ｛ｓｔ ａｔｕｓ ＰＫＩＳｔａｔｕｓ，ｓｔ ａｔｕｓＳｔｒｉｎｇ ＰＫＩＦｒｅｅＴｅｘｔ ＯＰＴＩＯＮＡＬ，ｆａｉ ｌＩｎｆｏ ＰＫＩＦａｉｌｕｒｅＩｎｆｏ ＯＰＴＩＯＮＡＬ）９）确认协议确认消息会在ＰＫＩＨｅａｄｅｒ中带着所需的所有信息。因此，该数据结构内容为空。 ＰＫＩ ＣｏｎｆｉｒｍＣｏｔｅｎｔ：：＝ＮＵＬＬｈ）证书识别为了识别特定的证书， 采用了ＣｅｒＩｄ结构ＣｅｒＩｄ：：＝ＳＥＱＵＥＮＣＥ｛ ｉ ｓｓｕｅｒ ＧｅｎｅｒａｌＮａｍｅ，ｓ ｅｒｉａｌＮｕｍｂｅｒ ＩＮＴＥＧＥＲ｝ｉ） Ｃｅｎｔｒａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ｋｅｙｓ本标准规定由第三方集中产生加密密钥对并通过带外方式提供给ＣＡ，此时ＣＡ用Ｃｅｒｔｉ ｆｉｅｄ－Ｋｅ ｙＰａｉｒ结构发还证书。 ＣｅｒｔｉｆｉｅｄＫｅｙＰａｉｒ：：二ＳＥＱＵＥＮＣＥ｛ｃｅｒｔｉ ｆｉｃａｔｅ ［０］ Ｃｅｒｔｉｆｉｃａｔｅ ＯＰＴＩＯＮＡＬ， ｅｎｃｒｙｐｔｅｄＣｅｒｔ ［１］ ＥｎｃｒｙｐｔｅｄＶａｌｕｅ ＯＰＴＩＯＮＡＬ，ｐｒｉ ｖａｔｅＫｅｙ ［２］ ＥｎｃｒｙｐｔｅｄＶａｌｕｅ ＯＰＴＩＯＮＡＬ，ｐｕｂｌ ｉｃａｔｉｏｎＩｎｆｏｉ ｎｔｅｎｄｅｄＡｌｇ巨３］ ＰＫＩＰｕｂｌｉｃａｔｉｏｎＩｎｆｏ ＯＰＴＩＯＮＡＬ｝仁０］ ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，ＥｎｃｒｙｐｔｅｄＶａｌ ｕｅ：：＝ＳＥＱＵＥＮＣＥ｛一ｔ ｈｅ ｉｎｔｅｎｄｅｄ ａｌｇｏｒｉｔｈｍ ｆｏｒ ｗｈｉｃｈ ｔｈｅ ｖａｌｕｅ ｗｉｌｌ ｂｅ ｕｓｅｄ ｓｙｍｍＡｌｇ ［１］ ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，一加密这一ｖａｌ ｕｅ的对称算法ｅｎｃＳｙｍｍＫｅｙ 仁２］ ＢＩＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ， 一用来加密这一ｖａｌｕｅ的对称密钥（已加密）ｋｅｙＡｌ ｇ ［３］ ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，ＧＢ／Ｔ １９７７１－２００５一用来加密对称密钥的算法 ｖａｌ ｕｅＩ－ｌｉｎｔ仁４］ ＯＣＴＥＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ，一ｅｎｃＶａ ｌｕｅ内容的简要描述或标识符一（可能只对发送实体有意义，仅当将来发送实体对Ｅｎｃｒｙｐｔ ｅｄＶａｌｕｅ重新检查时使用）ｅｎｃＶａｌ ｕｅ ＢＩＴ ＳＴＲＩＮＧ一加密的ｖａｌ ｕｅ｝ｊ）带外信息 为了在带外传输一个ＣＡ的公钥， 采用了ＯＯＢＣｅｒｔ结构。ＯＯＢＣｅｒｔ只是一个ＣＡ的证书。ＯＯＢＣｅｒｔ：：＝Ｃｅｒｔｉ ｆｉｃａｔｅ６．５．４特殊操作的数据结构ａ）注册／证书请求 注册和证书请求消息（ｃ ｒ）包含一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ的数据结构，该结构规范了请求证书的特定取值。 Ｃｅ ｒｔＲｅｇＭｅｓｓａｇｅｓ是ＣｅｒｔＲｅｇＭｓｇ结构的一个或多个序３４１．ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ：：＝ＳＥＱＵＥＮＣＥ ＳＩＺＥ（Ｉ二ＭＡＸ） ＯＦ ＣｅｒｔＲｅｇＭｓｇ 例外的，本标准里定义的事务假设ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ仅是一个ＣｅｒｔＲｅｇＭｓｇ的ＳＥＱＵＥＮＣＥｏ同时请签名证书和加密证书的可选事务请求要求Ｃｅｒ ｔＲｅｇＭｅｓｓａｇｅｓ是大小为２的ＳＥ－ＱＵＥＮＣＥ。本标准不鼓励同时申请两个证书， 但不禁止。ｂ）注册／证书响应 注册响应消息（ｃｐ）包含一个ＣｅｒＲｅｐＭｅｓｓａｇｅ结构（一个可选的公钥和一个ｒｅｓｐｏｎｓｅ）。特别的， 本标准里定义的事务都假设响应仅是一个ＣｅｒｔＲｅｓｐｏｎｓｅ的序列。一个例外就是含有签名证书和加密证书请求的事务； 该事务的响应可以是响应消息的结合，即含有两个ＣｅｒｔＲｅ－ｓｐｏｎｓｅ的字段的序列。 Ｃｅｒ ｔＲｅｓｐｏｎｓｅ包含一个请求ｉｄ、状态信息和一个ＣｅｒｔｉｆｉｅｄＫｅｙＰａｉｒ（可选）。ＣｅｒｔｉｆｉｅｄＫｅｙＰａｉｒ是一个包含四个可选字段的序列，四个可选字段分别是：一个证书，一个已加密证书、一个已 加密私钥，以及公开信息。本标准中，证书字段总出现在ＣｅｒｔｉｆｉｅｄＫｅｙＰａｉｒ里。仅当集中产生密钥管理密钥时才用到Ｐｒ ｉｖａｔｅＫｅｙ，其余字段均不出现。Ｃｅｒｔ ＲｅｐＭｅｓｓａｇｅ：：＝ＳＥＱＵＥＮＣＥ｛ ｃａＰｕｂ ［１］ Ｃｅｒｔｉｆｉｃａｔｅ ＯＰＴＩＯＮＡＬ，ｒｅｓｐｏｎｓｅ ＳＥＱＵＥＮＣＥ ＯＦ ＣｅｒｔＲｅｓｐｏｎｓｅ｝Ｃｅｒｔ Ｒｅｓｐｏｎｓｅ：：＝ＳＥＱＵＥＮＣＥ｛ｃｅ ｒｔＲｅｇＩｄ ＩＮＴＥＧＥＲ，一与相应的请求相匹配ｃｅｒ ｔＲｅｐＳｔａｔｕｓ ＰＫＩＳｔａｔｕｓＩｎｆｏ，ｃｅｒ ｔｉｆｉｅｄＫｅｙＰａｉｒ ＣｅｒｔｉｆｉｅｄＫｅｙＰａｉｒ ＯＰＴＩＯＮＡＬ；一只有当状态为ｇｒ ａｎｔｅｄ或ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ才存在ｒｓｐＩｎｆ ｏ ＯＣＴＥＴ ＳＴＲＩＮＧ ＯＰＴＩＯＮＡＬ一ａｎａｌ ｏｇｏｕｓ ｔｏ ｔｈｅ ｉｄ－ｒｅｇＩｎｆｏ－ａｓｃｉｉＰａｉｒｓ ＯＣＴＥＴ ＳＴＲＩＮＧ ｄｅｆｉｎｅｄ 一ｆｏｒ ｒｅｇＩｎｆｏ ｉｎ ＣｅｒｔＲｅｇＭｓｇ巨ＣＲＭＦ］｝如果ｃ ｅｒｔＲｅｐＳｔａｔｕｓ包含ｆａｉｌＩｎｆｏ字段，ＣｅｒｔＲｅｓｐｏｎｓｅ将不包含ｃｅｒｔｉｆｉｅｄＫｅｙＰａｉｒ并且ｃｅｒｔＲｅｐ－Ｓｔ ａｔｕｓ字段的ｓｔａｔｕｓ的值将是ｒｅｊｅｃｔｉｏｎ． ｓｔａｔｕｓ的值是ｗａｉｔｉｎｇ时，可选字段就都不出现。ｓ ｔａｔｕｓ的值ｒｅｖｏｃａｔｉｏｎＷａｒｎｉｎｇ和ｒｅｖｏｃａｔｏｎＮｏｔｉｆｉｃａｔｉｏｎ不会在消息中出现。ｃａＰｕｂ和ｒｓｐＩ ｎｆ。字段是不需要的，如果它们出现的话可以被忽略。本标准并不使用Ｃｅｒｔｉ－ｆｉ ｅｄＫｅｙＰａｉｒ中的ｅｎｃｒｙｐｔｅｄＣｅｒｔ和ｐｕｂｌｉｃａｔｉｏｎＩｎｆｏ字段。ＧＢ／Ｔ １９７７１－２００５ｃ）撤销请求的内容当请求撤销一个证书时采用以下数据结构。请求者的名字在ＰＫＩ Ｉ－ｌｅａｄｅｒ中显示。ＲｅｖＲｅｇＣｏｎｔｅｎｔ：：＝ＳＥＱＵＥＮＣＥ ＯＦ ＲｅｖＤｅｔａｉｌｓＲｅ ｖＤｅｔａｉｌｓ：：＝ＳＥＱＵＥＮＣＥ ＯＦ｛ ｃｅｒｔＤｅｔａｉｌｓ ＣｅｒｔＴｅｍｐｌａｔｅ，一允许请求者尽可能多的指定所请求撤销的证书的参数（例如，不知道序列号时） ｒｅｖｏｃａｔｉ ｏｎＲｅａｓｏｎ ＲｅａｓｏｎＦｌａｇｓ，一来自ＤＡＭ，这样ＣＡ就知道该用哪个Ｄｉ ｓｔ． ｐｏｉｎｔ ｂａｄＳｉｎｃｅＤａｔｅ ＧｅｎｅｒａｌｉｚｅｄＴｉｍｅ ＯＰＴＩＯＮＡＬ，一ｉ ｎｄｉｃａｔｅｓ ｂｅｓｔ ｋｎｏｗｌｅｄｇｅ ｏｆ ｓｅｎｄｅｒｃｒｌ ＥｎｔｒｙＤｅｔａｉｌｓ Ｅｘｔｅｎｓｉｏｎｓ一要求的ｃｒ ＩＥｎｔｒｙＥｘｔｅｎｓｉｏｎｓ）ＲｅａｓｏｎＦｌ ａｇｓ定义见附录Ｂ。为清楚起见这里再说明一遍。Ｒｅ ａｓｏｎＦｌａｇｓ：：＝ＢＩＴ ＳＴＲＩＮＧ｛ ｕｎｕｓｅｄ （０），ｋｅｙＣｏｍｐｒｏｍｉ ｓｅ（１）， ｃａＣｏｍｐｒｏｍｉｓｅ （２），ａｆ ｆｉｌｉａｔｉｏｎＣｈａｎｇｅｄ （３），ｓｕｐｅｒ ｓｅｄｅｄ （４）， ｃｅｓｓａｔｉｏｎ０ｆＯｐｅｒａｔｉｏｎ （５），ｃｅｒｔｉ ｆｉｃａｔｅＨｏｌｄ （６），ｒ ｅｍｏｖｅＦｒｏｍＣＲＬ （８）｝ｂａｄＳｉ ｎｃｅＤａｔｅ和ｒｅｖｏｃａｔｉｏｎＲｅａｓｏｎ表示的信息可以在ｃｒＩＥｎｔｒｙＤｅｔａｉｌｓ中也同样表示出来，使用标准的Ｘ． ５０９ ＣＲＩ，扩展ｉｎｖａｌｉｄｉｔｙＤａｔｅ和ｒｅａｓｏｎＣｏｄｅ。推荐的位置是ｃｒｌＥｎｔｒｙＤｅｔａｉｌｓ，不过本标准建议ＣＡ处理其他位置的信息。当有冲突存在的时候， 使用较早的日期。当撤销原 因不匹配时，ＣＡ应包括所有的原因。ｄ）撤销响应内容当对撤销请求做响应时， 使用以下数据结构。把它发送给请求者。Ｒｅ ｖＲｅｐＣｏｎｔｅｎｔ：：＝ＳＥＱＵＥＮＣＥ｛ｓｔ ａｔｕｓ ＰＫＩＳｔａｔｕｓｌｎｆｏ，ｒ ｅｖＣｅｒｔｓ ［０］ ＳＥＱＵＥＮＣＥ ＯＦ Ｃｅｒｔｌｄ ＯＰＴＩＯＮＡＬ，一确定要请求撤销的证书 ｃｒｌｓ ［１］ ＳＥＱＵＥＮＣＥ ＯＦ ＣｅｒｔｉｆｉｃａｔｅＬｉｓｔ ＯＰＴＩＯＮＡＬ，一作为结果的相应的ＲＬ｝ 在本标准中，ｒｅｖＣｅｒｔｓ是一个或多个ＣｅｒｔＩ Ｄ字段的ＳＥＱＵＥＮＣＥ， ｃｒｌｓ字段并不出现。ｅ） ＰＫＣＳ ＃ １０证书请求这个证书请求句法在ＲＦＣ ２３１４中有定义，为清楚起见在此重复一遍。 ＰＫＣＳＩ ＯＣｅｒｔＲｅｇＣｏｎｔｅｎｔ：：＝ＳＥＱＵＥＮＣＥ｛ｃｅｒｔｉ ｆｉｃａｔｉｏｎＲｅｑｕｅｓｔＩｎｆｏ ＣｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ ｓｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍ Ｓｉｇｎａｔｕｒｅ ＡｌｇｏｒｉｔｈｍＩｄｅｎｔｉｆｔｅｒ，ｓｉ ｇｎａｔｕｒｅ Ｓｉｇｎａｔｕｒｅ）Ｓｉ ｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍｌｄｅｎｔｉｆｉｅｒ：：二ＡｌｇｏｒｉｔｈｍｌｄｅｎｔｉｆｉｅｒＳｉ ｇｎａｔｕｒｅ：：＝ＢＩＴ ＳＴＲＩＮＧＧＢ／Ｔ １９７７１－２００５Ｃｅｒｔｉ ｆｉｃａｔｉｏｎＲｅｑｕｅｓｔＩｎｆｏ：：＝ＳＥＱＵＥＮＣＥ｛ｖｅｒｓｉ ｏｎ Ｖｅｒｓｉｏｎ，ｓｕｂｊ ｅｃｔ Ｎａｍｅ， ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙｌｎｆｏ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙｌｎｆｏ，ａｔ ｔｒｉｂｕｔｅｓ ［０」 ＩＭＰＬＩＣＩＴ Ａｔｔｒｉｂｕｔｅｓ）Ｖｅｒｓｉ ｏｎ：：＝ＩＮＴＥＧＥＲＡｔｔｒ ｉｂｕｔｅｓ：：＝ＳＥＴ ＯＦ Ａｔｔｒｉｂｕｔｅ Ａｔｔｒｉｂｕｔｅｓ在ＲＦＣ ２９８５中有定义。为了互操作而对Ａｔｔｒｉｂｕｔｅｓ的支持是可选的。即使出现了，也可以被忽略。 ６． ６ ＰＫＩ事务６． ６． １ ＰＫＩ事务概述本条详细介绍了ＰＫＩ的具体功能：注册请求、更新和撤销证书。也简要描述了访问目录服务的 事务。ＣＡ，ＲＡ和证书持有者应能实现本条描述的所有事务。 对于ＣＡ和ＲＡ物理上在一起、不支持远端ＲＡ的ＰＫＩ产品，ＣＡ和ＲＡ之间的消息就可以忽略掉。 ６． ６． ２ ＲＡ发起的注册请求ＲＡ可以请求ＣＡ为一个终端实体颁发签名证书。这个事务分五步执行。第一步，终端实体通过 带外事务（例如通过实际呈交一个磁盘）在一个签名消息中向ＲＡ提供一个公钥。第二步，ＲＡ通过一个签名消息向ＣＡ请求证书。第三步，ＣＡ通过一个含有证书或错误代码的签名消息回应ＲＡ。第四步ＲＡ通过带外方式向终端实体提供ＣＡ的公钥和所颁发的证书（若是集中产生密钥对则还包括相应私钥），终端实体也可以直接从ＣＡ获得。第五步ＲＡ向ＣＡ发出确认消息。在这个过程中包括三条消息。 ａ）从ＲＡ到ＣＡ的证书请求ＲＡ建立一个ＰＫＩ Ｂｏｄｙ为ｃｒ的ＰＫＩＭｅｓｓａｇｅ。其ＰＫＩＨｅａｄｅｒ包括下列信息：ｐｖｎｏ是１； ｔ ｒａｎｓａｃｔｉｏｎＩＤ是该ＲＡ赋予这个事务的唯一整数； ｍｅｓｓａｇｅＴｉｍｅ是当前精确到秒的时间；ｓｅｎｄｅｒ是ＲＡ的可辨别名； ｒ ｅｃｉｐｉｅｎｔ是ＣＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用来保护该消息的签名算法的算法标识符。这个消息的消息体是ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ，它是一个或多个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ字段的序列。对于 这个事务， ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ是一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ的序列。这个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ将包括如下信息： ｃ ｅｒｔＲｅｑ含有请求者希望包含在证书中的信息； ＰＯＰ证明了对新证书私钥的拥有。本标准中只支持终端实体产生签名密钥对，不支持终端实体产生加密密钥对。在进行签名私 如果由ＲＡ来实现，钥的拥有性证明时，那么ＲＡ修改了主体名，ｐｏｐｏＳＫＩｎｐｕｔ域出现，并且包含了原来的主体名。否则， ＲＡ不修改主体名，那么ｐｏｐ域与请求者提交的主体名一致。详细原理见６．５．３０ ｃｅｒｔＲｅｑ是Ｃｅｒｔ Ｒｅｑｕｅｓｔ，它是一个ｃｅｒｔＲｅｇＩＤ、一个ＣｅｒｔＴｅｍｐｌａｔｅ和ｃｏｎｔｒｏｌｓ的序列。对于这个事务， ｃｅｒｔＲｅｇＩＤ可以是任何整数。Ｃｅｒ ｔＴｅｍｐｌａｔｅ将含有如下信息：ｖｅｒｓｉ ｏｎ是ｖ３（２）；ＧＢ／Ｔ １９７７１－２００５ｓｕｂｊ ｅｃｔ是用户的名字；ｐｕｂｌ ｉｃＫｅｙ提供了新证书的公钥，若用集中方式产生密钥对则不包括该字段；ｅｘｔ ｅｎｓｉｏｎｓ至少指定了与证书有关的证书策略的ＯＩＤ．如下的信息可以被包含在Ｃｅｒ ｔＴｅｍｐｌａｔｅ中：ｓ ｉｇｎｉｎｇＡｌｇ指定了首选签名算法； ｓｕｂｊｅｃｔ指定了潜在证书持有者的可辨别名。请求不应该包括如下信息： ｉ ｓｓｕｅｒＵＩＤ； ｓｕｂｊｅｃｔＵＩＤ，ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＲＡ的签名。ｂ）从ＣＡ到ＲＡ的证书回应ＣＡ将返回以元素ｃｐ为ＰＫＩ Ｂｏｄｙ的ＰＫＩＭｅｓｓａｇｅ给ＲＡａ ＰＫＩＨｅａｄｅｒ包括如下信息：ｐｖｎｏ是１； ｔ ｒａｎｓａｃｔｉｏｎＩＤ与ｃｒ消息中的ｔｒａｎｓａｃｔｉｏｎｌＤ相同；ｍｅｓｓ ａｇｅＴｉｍｅ是当前精确到秒的时间； ｓｅｎｄｅｒ是ＣＡ的可辨别名；ｒｅｃｉ ｐｉｅｎｔ是ＲＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用来保护该消息的签名算法的算法标识符。如果ｓｅｎｄｅｒＮｏｎｃｅ在证书请求中被提供了，那么这个回应的消息头应该将其作为ｒｅｃｉ ｐＮｏｎｃｅ ｏＰＫＩ Ｂｏｄｙ元素ｃｐ是ＣｅｒｔＲｅｐＭｅｓｓａｇｅ类型。对于这个事务，ＣｅｒｔＲｅｐＭｅｓｓａｇｅ将含有唯一的ｒ ｅｓｐｏｎｓｅ字段。该ｒｅｓｐｏｎｓｅ字段是一个ｃｅｒｔＲｅｑｌｄ， ｓｔａｔｕｓ和ｃｅｒｔｉｆｉｅｄＫｅｙＰａｉ：的序列。如果ＣＡ颁发了一个证书，消息体将含有如下消息： ｃｅｒｔＲｅｇＩｄ将与请求中的ｃｅｒｔＲｅｇＩｄ匹配；ｓｔａｔｕｓ将是ｇｒａｎｔｅｄ或者是ｇｒａｎｔｅｄＷｉ ｔｈＭｏｄｓ；ｃｅｒｔ ｉｆｉｅｄＫｅｙＰａｉｒ序列将至少含有一个字段—ｃｅｒｔｉｆｉｃａｔｅ，其将含有ＧＢ／Ｔ １６２６４． ８－ ２００５的证书。证书必须满足如下性质： ｖｅｒｓｉｏｎ号应该是ｖ３（２）；ｐｕｂｌ ｉｃＫｅｙ字段应该与证书请求中相同或者是由ＣＡ所产生的公钥；主体可辨别名应该与证书请求中相同； 颁发者名字应该是ＣＡ的可辨别名；如果ｎｏｔＢｅｆ ｏｒｅ出现在证书请求中，证书应该从颁发日和ｎｏｔＢｅｆｏｒｅ所指之日的较晚者之后生效； 如果ｎｏｔＡｆｔｅｒ出现在证书请求中，证书应该在该日或之前期满。证书应该包括如下扩展（ｅｘｔ ｅｎｓｉｏｎｓ） ：ｓｕｂｊｅｃｔ ＫｅｙＩｄｅｎｔｉｆｉｅｒ域；在ｃｅｒｔｉ ｆｉｃａｔｅＰｏｌｉｃｉｅｓ字段中至少包括一个证书策略的ＯＩＤ；包括ＫｅｙＩ ｄｅｎｔｉｆｉｅｒ字段的权威密钥标识符。如果在证书请求消息中指定一个特定的密钥标识符， 那么证书的ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅ：字段应该就是该密钥标识符。如果没有具体指明密钥标识符，ＣＡ将用主体公钥的低９６位ＳＨＡ－１ 散列函数作为ｓ ｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ字段中的ＫｅｙＩｄｅｎｔｉｆｉｅｒ。散列函数是通过对证书中主体公钥字段的值（不包括标签和长度）进行计算得到的。 ＧＢ／Ｔ １９７７１－２００５ 如果颁发者的证书或是ＣＲＬｓ不提供Ｘ． ５００目录服务，证书就应含有ｉｓｓｕｅｒＡｌｔＮａｍｅ扩展中的ＵＲＬｓ以及ＣＲＬＤｉ ｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展中的ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段。如果ｓ ｔａｔｕｓ是ｇｒａｎｔｅｄ和ｇｒａｎｔｅｄＷ ｉｔｈＭｏｄｓ，那么ｆａｉｌＩｎｆｏ字段可以不存在。 若ＣＡ拒绝了请求，则正文中包含以下信息：ｓｔ ａｔｕｓ将是ｒｅｊｅｃｔｅｄ； ｆａｉｌＩｎｆｏ字段包含相应的错误码：．ｂａ ｄＡｌｇ说明ＣＡ不能验证签名，因为算法标识符无法识别或者不支持，令ｂａ ｄＭｅｓｓａｇｅＣｈｅｃｋ说明ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段中的ｍａｃ被检验，但是不匹配，．ｂａ ｄＰｏＰ说明ｐｏｐｏＳｉｇｎｉｎｇＫｅｙ字段中的签名已经被检验，但是不匹配，．ｂａ ｄＲｅｑｕｅｓｔ说明响应者不允许或不支持该事务请求， ．ｂａｄＴｉｍｅ说明消息头中的ｍｅｓｓａｇｅＴｉｍｅ字段中的时间与响应者的系统时间差别太大； 如果ｓ ｔａｔｕｓ是ｒｅｊｅｃｔｅｄ，那么ｃｅｒｔｉｆｉｅｄＫｅｙＰａｉ：字段可以不出现。 ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＣＡ的签名。ｃ）确认消息 一旦接收到ｃｐ，ＲＡ应该产生ＰＫＩ Ｃｏｎｆｉｒｍ消息。确认消息的ＰＫＩＨｅａｄｅｒ中的数据除了ｍｅｓ－ｓａｇｅＴｉ ｍｅ之外，应该与证书请求消息的ＰＫＩＨｅａｄｅｒ中的数据相同。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＲＡ的签名。６．６．３新实体的自我注册请求一个新的实体如果从来没有从一个特定ＣＡ获得证书， 他可以直接向那个ＣＡ申请一个新的证书。请求实体生成一个ＰＫＩ ｉｔ消息来请求新证书，并在消息中包含和证书请求中公钥相对应的私钥的拥有证明。实体利用ＲＡ提供的一个秘密密钥和ＳＨＡ－１ ＨＭＡＣ算法保护ＰＫＩ消息。 如果ＣＡ接受自我注册请求，它将返回一个ｉｐ消息给证书持有者。该消息包含证书或者事务出错的原因代码。 ａ） ＲＡ与实体的带外事务自我注册申请证书的过程以ＲＡ和实体之间交换一个共享的秘密密钥开始。通过从共享的秘 密中产生一个消息认证码，ＣＡ能够对实体进行认证。这里不指定这个带外事务的明确的内容和格式。但是秘密的密钥和可信ＣＡ的公钥信息应该 以一种可信的方式传递给实体。ｂ）从证书持有者到ＣＡ的自我注册请求 请求者建立一个ＰＫＩ Ｂｏｄｙ为ｉ：的ＰＫＩＭｅｓｓａｇｅｏ ＰＫＩＨｅａｄｅｒ包括如下信息：ｐｖｎｏ是１； ｍｅｓ ｓａｇｅＴｉｍｅ是当前精确到秒的时间；ｓｅｎｄｅｒ是请求者的可辨别名或一个电子邮件地址； ｒ ｅｃｉｐｉｅｎｔ是ＣＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用来保护消息的签名算法的算法标识符。 这个消息的消息体是ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ，它是一个或多个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ字段的序列。对于这个事务， ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ是一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ的序｝Ｖ１ｌ。这个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ将包括如下信息： ｃ ｅｒｔＲｅｑ含有请求者希望包含在证书中的信息； ｐｏｐｏＳＫＩｎｐｕｔ包含公钥的ｍａｃ值；ｐｏｐ证明了对证书私钥的拥有。 其中ｐｏｐ域通过与Ｃｅｒ ｔＴｅｍｐｌａｔｅ中的公钥相对应的私钥来产生，产生ｐｏｐ的输入数据包括ＧＢ／Ｔ １９７７１－２００５ｐｏｐｏＳＫＩ ｎｐｕｔ中的公钥ｍａｃ值和ＣｅｒｔＴｅｍｐｌａｔｅ中的公钥。 ｃｅｒｔＲｅｑ是一个ＣｅｒｔＲｅｑｕｅｓｔ，它是一个ｃｅｒｔＲｅｇｌＤ，一个ＣｅｒｔＴｅｍｐｌａｔｅ和ｃｏｎｔｒｏｌｓ的序列。对于这个事务： ｃｅｒｔＲｅｇＩ Ｄ是任何整数；ｃ ｅｒｔＴｅｍｐｌａｔｅ是一个ＣｅｒｔＴｅｍｐｌａｔｅ，其至少包括为新证书提供公钥的ｐｕｂｌｉｃＫｅｙ字段；ｃ ｏｎｔｒｏｌｓ被省略。 ＣｅｒｔＴｅｍｐｌａｔｅ将含有如下信息：ｖｅｒｓｉ ｏｎ是ｖ３（２）；ｐｕｂｌ ｉｃＫｅｙ提供了新证书的公钥。如下的信息可以被包含在Ｃｅ ｒｔＴｅｍｐｌａｔｅ中：ｓ ｉｇｎｉｎｇＡｌｇ指定了首选签名算法； ｓｕｂｊｅｃｔ指定了潜在证书持有者的可辨别名；ｅｘｔｅｎｓｉ ｏｎｓ至少指定了与证书有关的证书策略的ＯＩＤ．请求不应该包括如下信息： ｉ ｓｓｕｅｒＵＩＤ；ｓｕｂｊ ｅｃｔＵＩＤ， ＰＫＩＰｒｏｔｅｃｔｉｏｎ域包含一个请求者利用从ＲＡ获得的秘密产生的值。实体利用ＲＡ提供的秘密密钥产生一个９６ｂｉ ｔ的ＳＨＡ１－ＨＭＡＣ， ｐｒｏｔｅｃｔｉｏｎＡｌｇ域应该设成ＳＨＡＴ－ＨＭＡＣ， ＰＫＩＰｒｏ－ｔ ｅｃｔｉｏｎ的值应该是９６位的消息认证码。计算ＰＫＩＰｒｏｔｅｃｔｉｏｎ的输入是如下数据结构的ＤＥＲ编码： Ｐｒ ｏｔｅｃｔｅｄＰａｒｔ：：＝＝ＳＥＱＵＥＮＣＥ｛ＰＫＩＨｅａｄｅｒ， ＰＫＩＢｏｄｙ｝ ｃ）从ＣＡ到证书请求者的自我注册请求的回应ＣＡ将返回给证书持有者一个ＰＫＩ Ｂｏｄｙ为ｉｐ的ＰＫＩＭｅｓｓａｇｅ消息。ＰＫＩＨｅａｄｅｒ包含如下信息： ｐｖｎｏ是１； ｍｅｓ ｓａｇｅＴｉｍｅ是当前精确到秒的时间；ｓｅｎｄｅｒ是ＣＡ的可辨别名； ｒｅｃｉｐｉｅｎｔ是证书请求消息头中ｓｅｎｄｅｒ域的值；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用来保护消息的签名算法的算法标识符。如果ｉ ｔ消息中提供了ｔｒａｎｓａｃｔｉｏｎＩＤ，这个回应的消息头中将包括同样的ｔｒａｎｓａｃｔｉｏｎＩＤ。如果ｉ ｔ消息中提供了ｓｅｎｄｅｒＮ ｏｎｃｅ，这个回应的消息头中将包含ｒｅｃｉｐＮｏｎｃｅ ｏＰＫＩ Ｂｏｄｙ元素ｉｐ是ＣｅｒｔＲｅｐＭｅｓｓａｇｅ类型。如果ＣＡ颁发了一个证书，消息体将含有如下信息： ｓｔａｔｕｓ将是ｇｒａｎｔｅｄ或者是ｇｒａｎｔｅｄＷｉ ｔｈＭｏｄｓ； ｃｅｒｔｉｆｉｃａｔｅ包含新的ＧＢ／Ｔ １６２６４． ８－２００５的证书。如果ｓｔ ａｔｕｓ是ｇｒａｎｔｅｄ或者是ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ，ｆａｉｌＩｎｆｏ域可以不存在。如果ＣＡ拒绝了请求，消息体将含有如下信息： ｓ ｔａｔｕｓ将是ｒｅｊｅｃｔｅｄ；ｆ ａｉｌＩｎｆｏ包含适当的错误代码： ．ｂａｄＡｌｇ说明ＣＡ不能验证签名，因为算法标识符无法识别或者不支持，今ｂａｄＭｅｓ ｓａｇｅＣｈｅｃｋ说明ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段中的ｍａｃ被检验，但是不匹配，ＧＢ／Ｔ １９７７１－２００５今ｂａｄＰｏＰ说明ｐｏｐｏＳｉ ｇｎｉｎｇＫｅｙ字段中的签名已经被检验，但是不匹配，令 ｂａｄＲｅｑｕｅｓｔ说明响应者不允许或不支持该事务请求，．ｂａｄＴｉ ｍｅ说明消息头中的ｍｅｓｓａｇｅＴｉｍｅ字段中的时间与响应者的系统时间差别太大， ．ｂａｄＣｅｒ ｔＩＤ表明ＣｅｒｔＤｅｔａｉｌｓ中的信息无法确定一个未过期、未撤销的证书；如果ｓｔ ａｔｕｓ是ｒ句ｅｃｔｅｄ， ｃｅｒｔｉｆｉｃａｔｅ域可能不存在，如果存在证书应该遵从于６． ２．１中定义的证 书轮廓。证书应该包括如下扩展（ｅｘｔ ｅｎｓｉｏｎｓ）；ｓｕｂｊ ｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ域； 在ｃｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ字段中至少包括一个证书策略的ＯＩＤ；包括Ｋｅ ｙｌｄｅｎｔｉｆｉｅ：字段的权威密钥标识符。如果在ｉ ｔ消息中指定一个特定的密钥标识符，那么证书的ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ字段应该就是 该密钥标识符。如果没有具体指明密钥标识符，ＣＡ将用主体公钥的低９６位ＳＨＡ－１散列函数作为ｓ ｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ字段中的Ｋｅｙｌｄｅｎｔｉｆｉｅｒ。散列函数是对证书中主体公钥字段的值（不包括标签和长度）计算得到的。 如果ｉ ｔ消息中包含了除ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ之外的其他扩展，ＣＡ将修改或者忽略该扩展。 如果颁发者的证书或是ＣＲＬｓ不提供Ｘ． ５００目录服务，证书就应含有ｉｓｓｕｅｒＡｌｔＮａｍｅ扩展中的ＵＲＩ ．ｓ以及ＣＲＩ．ＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展中的ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＣＡ的签名。ｄ）确认消息 一旦接收到ｉ ｐ，证书持有者应该产生一个ＰＫＩＣｏｎｆｉｒｍ消息。确认消息的ＰＫＩＨｅａｄｅ：中的数 ｍｅ之外，应该与证书请求消息的ＰＫＩＨｅａｄｅｒ中的数据相同。据除了ｍｅｓｓａｇｅＴｉ如果请求被接受，ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ域包含证书持有者的数字签名，利用与新的签名证书对应的 私钥对消息头和消息体的ＤＥＲ编码序列计算签名。如果请求被拒绝，ＰＫＩＰｒｏｔｅｃｔｉｏｎ域包含ＳＨＡ－ １ ＨＭＡＣ，利用共享秘密对消息头和消息体的ＤＥＲ编码计算。一旦接收到ＰＫＩ Ｃｏｎｆｉｒｍ， ＣＡ应该产生一个ＰＫＩＣｏｎｆｉｒｍ消息。确认消息的ＰＫＩＨｅａｄｅｒ中的 ｍｅ之外，应该与证书请求消息的ＰＫＩＨｅａｄｅｒ中的数据相同。数据除了ｍｅｓｓａｇｅＴｉＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＣＡ的签名。６．６．４已知实体的自我注册请求 一个实体不是当前的证书持有者，但是以前曾经从一个特定ＣＡ获得过证书，他可以直接向那个ＣＡ申请一个新的证书。请求实体生成一个ＰＫＩ ｃｒ消息来请求新证书，并在消息中包含与证书请求中公钥所对应的私钥的拥有证明。实体利用ＲＡ提供的一个秘密密钥和ＳＨＡ－１ ＨＭＡＣ算法保护ＰＫＩ消息。如果ＣＡ接受自我注册请求，它将返回一个ｃｐ消息给证书持有者。该消息包含证书或者事务出错 的原因代码。ａ） ＲＡ与实体的带外事务 自我注册申请证书的过程以ＲＡ传递一个共享的秘密密钥给实体开始。通过从共享的秘密中产生的一个消息认证码，ＣＡ能够对实体进行认证。 这里不指定这个带外事务的明确的内容和格式。但是秘密的密钥和可信ＣＡ的公钥信息应该 以一种可信的方式传递给实体。 ｂ）从证书持有者到ＣＡ的自我注册请求 请求者建立一个ＰＫＩＢｏｄｙ为ｃｒ的ＰＫＩＭｅｓｓａｇｅｏ ＰＫＩＨｅａｄｅｒ包括如下信息：ｐｖｎｏ是１； ＧＢＪＴ １９７７１－２００５ｍｅｓｓ ａｇｅＴｉｍｅ是当前精确到秒的时间；ｓｅｎｄｅｒ是请求者的可辨别名或一个电子邮件地址； ｒｅｃｉ ｐｉｅｎｔ是ＣＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用来保护消息的签名算法的算法标识符。 这个消息的消息体是ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ，它是一个或多个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ字段的序列。对于这个事务，ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ是一个Ｃｅｒｔ ＲｅｇＭｅｓｓａｇｅ的序列。这个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ将包括如下信息： ｃ ｅｒｔＲｅｑ含有请求者希望包含在证书中的信息；ｐ ｏｐｏＳＫＩｎｐｕｔ包含公钥的ｍａ。值；ｏｐ证明了对证书私钥的拥有。ｐ 其中ＰＯＰ域通过与Ｃｅｒ ｔＴｅｍｐｌａｔｅ中的公钥相对应的私钥来产生，产生ｐｏｐ的输人数据包括ｐｏｐｏＳＫＩｎｐｕｔ中的公钥ｍａｃ值和ＣｅｒｔＴｅｍｐｌ ａｔｅ中的公钥。ｃ ｅｒｔＲｅｑ是一个ＣｅｒｔＲｅｑｕｅｓｔ，它是一个ｃｅｒｔＲｅｇＩＤ，一个ＣｅｒｔＴｅｍｐｌａｔｅ和ｃｏｎｔｒｏｌｓ的序列。对于这个事务： ｃｅｒｔＲｅｇＩＤ是任何整数；Ｃｅ ｒｔＴｅｍｐｌａｔｅ是一个ＣｅｒｔＴｅｍｐｌａｔｅ，其至少包括为新证书提供公钥的ｐｕｂｌｉｃＫｅｙ字段。Ｃｅｒ ｔＴｅｍｐｌａｔｅ将含有如下信息：ｖｅｒｓｉ ｏｎ是ｖ３（２）； ｐｕｂｌｉｃＫｅｙ提供了新证书的公钥。如下的信息可以被包含在Ｃｅ ｒｔＴｅｍｐｌａｔｅ中：ｓ ｉｇｎｉｎｇＡｌｇ指定了首选签名算法；ｓｕｂｊｅｃｔ指定了潜在证书持有者的可辨别名。 ｅｘｔｅｎｓｉｏｎｓ至少指定了与证书有关的证书策略的ＯＩＤｏ请求不应该包括如下信息： ｉ ｓｓｕｅｒＵＩＤ； ｓｕｂｊｅｃｔＵＩＤ，ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ域包含一个请求者利用从ＲＡ获得的秘密产生的值。实体利用ＲＡ提供的秘密密钥产生一个９６ｂｉ ｔ的ＳＨＡ１－ＨＭＡＣ， ｐｒｏｔｅｃｔｉｏｎＡｌｇ域应该设成ＳＨＡＩ－ＨＭＡＣ， ＰＫＩＰｒｏ－ｔｅｃｔｉ ｏｎ的值应该是９６位的消息认证码。计算ＰＫＩＰｒｏｔｅｃｔｉｏｎ的输人是如下数据结构的ＤＥＲ编码： Ｐｒｏｔ ｅｃｔｅｄＰａｒｔ：：二ＳＥＱＵＥＮＣＥ｛ＰＫＩＨｅａｄｅｒ， ＰＫＩＢｏｄｙ｝ ｃ）从ＣＡ到证书请求者的自我注册请求的回应 ＣＡ将返回给证书持有者一个ＰＫＩＢｏｄｙ为ｃｐ的ＰＫＩＭｅｓｓａｇｅ消息。ＰＫＩＨｅａｄｅｒ包含如下信息： ｐｖｎｏ是Ｉ； ｍｅｓ ｓａｇｅＴｉｍｅ是当前精确到秒的时间；ｓｅｎｄｅｒ是ＣＡ的可辨别名； ｒ ｅｃｉｐｉｅｎｔ是证书请求消息头中ｓｅｎｄｅｒ域的值；ｐｒ ｏｔｅｃｔｉｏｎＡＩｇ是用来保护消息的签名算法的算法标识符。如果ｃｒ消息中提供了ｔ ｒａｎｓａｃｔｉｏｎＩＤ，这个回应的消息头中将包括同样的ｔｒａｎｓａｃｔｉｏｎＩＤ。如果ｃ ｒ消息中提供了ｓｅｎｄｅｒＮｏｎｃｅ，这个回应的消息头中将包含ｒｅｃｉｐＮｏｎｃｅｏＧＢ／Ｔ １９７７１－２００５ＰＫＩ Ｂｏｄｙ元素ｃｐ是ＣｅｒｔＲｅｐＭｅｓｓａｇｅ类型。如果ＣＡ颁发了一个证书，消息体将含有如下信息： ｓｔａｔｕｓ将是ｇｒａｎｔ ｅｄ或者是ｇｒａｎｔｅｄ Ｗｉｔｈ Ｍｏｄｓ；ｃ ｅｒｔｉｆｉｃａｔｅ包含新的ＧＢ／Ｔ １６２６４．８－２００５的证书。 如果ｓｔａｔｕｓ是ｇｒａｎｔｅｄ或者是ｇｒａｎｔ ｅｄＷｉｔｈＭｏｄｓ， ｆａｉｌｌｎｆｏ域可以不存在。如果ＣＡ拒绝了请求，消息体将含有如下信息： ｓｔａｔｕｓ将是ｒｅｊｅｃｔｅｄ；ｆ ａｉｌｌｎｆｏ包含适当的错误代码：．ｂａｄＡｌ ｇ说明ＣＡ不能验证签名，因为算法标识符无法识别或者不支持， 今ｂａｄＭｅｓｓａｇｅＣｈｅｃｋ说明ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段中的ｍａｃ被检验，但是不匹配，令ｂａｄＰｏＰ说明ｐｏｐｏＳｉ ｇｎｉｎｇＫｅｙ字段中的签名已经被检验，但是不匹配，．ｂａｄＲｅ ｑｕｅｓｔ说明响应者不允许或不支持该事务请求，令ｂａｄＴｉ ｍｅ说明消息头中的ｍｅｓｓａｇｅＴｉｍｅ字段中的时间与响应者的系统时间差别太大， 令ｂａｄＣｅｒｔ ＩＤ表明ＣｅｒｔＤｅｔａｉｌｓ中的信息无法确定一个未过期、未撤销的证书；如果ｓ ｔａｔｕｓ是ｒ哟ｅｃｔｅｄ， ｃｅｒｔｉｆｉｃａｔｅ域可能不存在，如果存在证书应该遵从于６． ２． １中定义的证书轮廓。 证书应该包括如下扩展（ｅ ｘｔｅｎｓｉｏｎｓ） ：ｓｕｂｊ ｅｃｔＫｅｙ１ｄｅｎｔｉｆｉｅｒ域； 在ｃｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ字段中至少包括一个证书策略的（）ＩＤ；包括Ｋｅｙｌ ｄｅｎｔｉｆｉｅｒ字段的权威密钥标识符。如果在。 ｒ消息中指定一个特定的密钥标识符，那么证书的ｓｕｂｊｅｃｔＫｅｙ１ｄｅｎｔｉｆｉｅｒ字段应该就是该密钥标识符。如果没有具体指明密钥标识符， ＣＡ将用主体公钥的低９６位ＳＨＡ－１散列函数作为ｓ ｕｂｊ ｅｃｔＫｅｙ１ｄｅｎｔｉｆｉｅｒ字段中的Ｋｅｙｌｄｅｎｔｉｆｉｅｒ。散列函数是对证书中主体公钥字段的值（不包括标签和长度）计算得到的。 如果ｃ ｒ消息中包含了除ｓｕｂｊｅｃｔＫｅｙ１ｄｅｎｔｉｆｉｅｒ之外的其他扩展，ＣＡ将修改或者忽略该扩展。 如果颁发者的证书或是ＣＲＩ．ｓ不提供Ｘ． ５００目录服务，证书就应含有ｉｓｓｕｅｒＡｌｔＮａｍｅ扩展中的ＵＲＬｓ以及ＣＲＬＤｉ ｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展中的ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段。ＰＫＩＰｒｏｔｅｃｔ ｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＣＡ的签名。ｄ＞确认消息 一旦接收到ｃｐ，证书持有者应该产生一个ＰＫＩＣｏｎｆｉｒｍ消息。确认消息的ＰＫＩＨｅａｄｅｒ中的数据除了ｍｅｓｓａｇｅＴｉ ｍｅ之外，应该与证书请求消息的ＰＫＩＨｅａｄｅｒ中的数据相同。如果请求被接受，ＰＫＩＰｒｏｔｅｃｔｉ ｏｎ域包含证书持有者的数字签名，利用与新的签名证书对应的私钥对消息头和消息体的ＤＥＲ编码序列计算签名。如果请求被拒绝，ＰＫＩＰｒｏｔｅｃｔ ｉｏｎ域包含 ＳＨＡ－１ ＨＭＡＣ，利用共享秘密对消息头和消息体的ＤＥＲ编码计算。一旦接收到ＰＫＩ Ｃｏｎｆｉｒｍ，ＣＡ应该产生一个ＰＫＩＣｏｎｆｉｒｍ消息。确认消息的ＰＫＩＨｅａｄｅｒ中的数据除了ｍｅｓｓａｇｅＴｉ ｍｅ之外，应该与证书请求消息的ＰＫＩＨｅａｄｅｒ中的数据相同。 ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段含有根据消息头和消息体的ＤＥＲ编码序列计算的ＣＡ的签名。６．６．５证书更新拥有当前有效（指在有效期内、未被撤销）证书的ＰＫＩ实体可以直接向该证书的签发ＣＡ要求签发 一份新的证书。ＰＫＩ实体生成ＰＫＩ ｋｒ（Ｋｅｙ ｕｐｄａｔｅ Ｒｅｑｕｅｓｔ密钥更新申请）消息，信息中包括了证书申请和相应的ＰＯＰ。然后ＰＫＩ实体使用有效证书的对应私钥对ＰＫＩ ｋｒ消息进行签名。如果ＣＡ的ＣＰＳ支持证书更新， 则ＣＡ返回ｋｐ （Ｋｅｙ ｕｐｄａｔｅ ｒｅｓｐｏｎｓｅ密钥更新响应）消息。ｋｐ消ＧＢ／Ｔ １９７７１－２００５息包含了新生成的证书或者是事务失败的代码。 如果新证书成功生成，则可能还有两个可选的消息。分别是：ＰＫＩ实体在收到新的证书后，给ＣＡ发出确认；然后ＣＡ也可回应一个确认消息。 ａ）从证书持有者到ＣＡ的证书更新申请证书持有者生成ＰＫＩ Ｂｏｄｙ是ｋｒ的ＰＫＩＭｅｓｓａｇｅ， ＰＫＩＭｅｓｓａｇｅ中的ＰＫＩＨｅａｄｅｒ包括了如下信息： ｐｖｎｏ是１； ｍｅｓｓ ａｇｅＴｉｍｅ是精度到秒的当前时间；ｓｅｎｄｅｒ是证书持有者的可辨别名； ｒｅｃｉ ｐｉｅｎｔ是ＣＡ的可辨别名； ｐｒｏｔｅｃｔｉｏｎＡｌｇ是用于保护消息签名算法ＩＤ．消息体是Ｃｅｒ ｔＲｅｇＭｅｓｓａｇｅｓ，是一个或者多个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ组成的序列。对于证书更新事务， ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ只能是包括了一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ的序列。在消息ＣｅｒｔＲｅｇＭｅｓｓａｇｅ中包括了如下信息： ｃ ｅｒｔＲｅｑ包含了申请者要求包括在证书中的各种信息；ｐｏｐ是新证书公钥的对应的ｐｏｐ证明。 ｐｏｐ必须是由ｐｕｂｌ ｉｃＫｅｙ域的公钥对应的私钥产生的。 ｃｅｒｔＲｅｑ是ＣｅｒｔＲｅｑｕｅｓｔ， ＣｅｒｔＲｅｑｕｅｓｔ是由一个ｃｅｒｔＲｅｇＩＤ、一个ｃｅｒｔＴｅｍｐｌａｔｅ和ｃｏｎｔｒｏｌｓ所组成的序列。对于证书更新事务： ｖｅｒｓｉ ｏｎ必须是ｖ３（２）； ｐｕｂｌｉｃＫｅｙ中是新证书的公钥。Ｃｅ ｒｔＴｅｍｐｌａｔｅ中可能包括了如下信息：ｓ ｉｇｎｉｎｇＡｌｇ指明了首选的签名算法；ｓｕｂｊｅｃｔ则是预期的证书持有者的可辨别名。 如果消息中没有ｓ ｉｇｎｉｎｇＡｌｇ，那么ＣＡ必须使用终端实体的公钥对应的算法签名。申请中不应该包括如下信息： ｉｓｓｕｅｒＵＩＤ；ｓｕｂｊｅｃｔＵＩ Ｄ．ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ域是使用当前有效证书的对应私钥对消息头和消息体的ＤＥＲ编码信息的签名结果。 ｂ）从ＣＡ到证书持有者的证书更新响应 ＣＡ生成ＰＫＩ Ｂｏｄｙ是ｋｐ的ＰＫＩＭｅｓｓａｇｅ， ＰＫＩＭｅｓｓａｇｅ中的ＰＫＩＨｅａｄｅｒ包括了如下信息：ｐｖｎｏ是１； ｍｅｓｓａｇｅＴｉｍｅ是精度到秒的当前时间；ｓｅｎｄｅｒ是ＣＡ的可辨别名； ｒｅｃｉ ｐｉｅｎｔ是证书持有者的可辨别名，也就是ｋｒ消息的ｓｅｎｄｅｒ；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用于保护消息签名算法ＩＤｏ 如果在ｋｒ消息中具有ｔｒａｎｓｔｉｏｎＩＤ，则ＣＡ回应消息的消息头中包括同样的ｔｒａｎｓｔｉｏｎＩＤ。如果在ｓｅｎｄｅｒＮｏｎｃｅ消息中具有ｓｅｎｄｅｒＮｏｎｃｅ，则ＣＡ回应消息的消息头中应该包括同样的ｒｅｃｉ ｐ－Ｎｏｎｃｅ ａ在ＰＫＩ Ｂｏｄｙ中，是ｋｐ元素。ｋｐ是ＣｅｒｔＲｅｐＭｅｓｓａｇｅ格式。如果ＣＡ签发了新证书，在消息体中应包括如下信息： ｓｔａｔｕｓ是ｇｒａｎｔｅｄ或者ｇｒ ａｎｔｅｄＷｉｔｈＭｏｄｓ；ＧＢ／Ｔ １９７７１－２００５ ｃｅｒｔｉｆｉｃａｔｅ是新生成的ＧＢ／Ｔ １６２６４． ８－２００５证书。新生成的证书应该包括如下扩展： ｓｕｂｊ ｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ域；在ｃ ｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ字段中至少包括一个证书策略ＯＩＤ；在ＫｅｙＩ ｄｅｎｔｉｆｉｅｒ域中有一个机构密钥标识符。ｃｅ ｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ扩展应该和当前有效证书一致。如果在ｋｒ消息中包含了密钥标识符信息，则证书中应该将其包含在ｓｕｂｊ ｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ；如果没有提供密钥标识符信息，则ＣＡ应该对证书公钥信息计算低９６ ｂｉｔ的ＳＨＡ－１摘要值作为ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ的值。摘要值是对证书中的主体公钥进行计算的，不包括标签和长度。 如果ｋｒ信息中包括了ｓｕｂｊ ｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ之后的扩展，则ＣＡ可以对其他的扩展信息进行修 改或者忽略。如果发布者的证书和ＣＲＬ不能够从已知的Ｘ． ５００目录中得到，则新证书中应该在ｉｓｓｕｅｒＡｌｔ－ Ｎａｍｅ中包括ＵＲＬｓ信息，在ＣＲＬＤｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ控制中包括ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ域。如果ｓｔ ａｔｕｓ是ｇｒａｎｔｅｄ或者ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ，则ｆａｉｌＩｎｆｏ域不存在。如果ＣＡ拒绝用户的申请，消息体包括如下信息： ｓｔａｔｕｓ是ｒ ｅｊｅｃｔｅｄ； ｆａｉｌＩｎｆｏ包括了合适的代码，可以是：．ｂａｄＡｌ ｇ表示ＣＡ不支持或者不认识ｋｒ指定的签名算法，令ｂａｄＰｏｐ表示ｐｏｐｏＳｉ ｇｎｉｎｇＫｅｙ域中的签名有误，令ｂａ ｄＭｅｓｓａｇｅＣｈｅｃｋ表示ＰＫＩＰｒｏｔｅｃｔｉｏｎ域中的签名有误，．ｂａ ｄＲｅｑｕｅｓｔ表示回应者不支持或者不允许该事务，．ｂａ ｄＴｉｍｅ表示消息头中的ｍｅｓｓａｇｅＴｉｍｅ的时间和回应者的系统时间相差太大，令ｂａ ｄＣｅｒｔＩｄ表示证书序号不能是ｓｅｒｉａｌ域中所填的非零值；如果ｓｔａｔｕｓ是ｒ ｅｊｅｃｔｅｄ， ｃｅｒｔｉｆｃａｔｅ域不存在。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ域包含了ＣＡ对于消息头和消息体的ＤＥＲ编码的签名。ｃ）确认消息 收到ｋｐ的时候，证书持有者应该产生ＰＫＩＣｏｎｆｉｒｍ消息。ＰＫＩＨｅａｄｅｒ中的信息和利用ＲＡ向ＣＡ申请证书的情况下的ＰＫＩＨｅａｄｅｒ一致，除了ｍｅｓｓａｇｅＴｉ ｍｅ是当前时间。如果证书更新申请被接受， 则ＰＫＩＰｒｏｔｅｃｔｉｏｎ是证书持有者使用新证书的对应私钥，对于消息 头和消息体的ＤＥＲ编码的签名。如果申请被拒绝，则ＰＫＩＰｒｏｔｅｃｔｉｏｎ是证书持有者使用当前有效证书的对应私钥，对于消息头和消息体的ＤＥＲ编码的签名。 收到ＰＫＩＣｏｎｆ ｉｒｍ的时候，ＣＡ应该产生ＰＫＩＣｏｎｆｉｒｍ消息。ＰＫＩＨｅａｄｅｒ中的信息和ｋｐ一致，除了ｍｅｓ ｓａｇｅＴｉｍｅ是当前时间。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ是ＣＡ对于消息头和消息体的ＤＥＲ编码的签名。６．６．６ ＰＫＣＳ ＃ １０自我注册请求目前不是证书持有者的实体可以用ＲＦＣ ２３１４定义的证书请求语句直接向ＣＡ申请证书。请求实体产生ＰＫＣＳＲｅｑ类型的ＰＫＩＭｅｓｓａｇｅ消息来申请证书，在证书请求中的正文里包括相应私钥的拥有证明，并用ＲＡ以带外方式提供的密钥来加密该ＰＫＩＭｅｓｓａｇｅ． ＣＡ返回一个证书请求响应消息给证书申请者。该消息将包含证书或处理失败原因代码。证书请求者和ＲＡ之间需用带外方式完成一个秘密消息的交换。 ａ）从证书持有者到ＣＡ的自我注册请求 请求者产生一个包含ＰＫＩＢｏｄｙ元素ｐ１０ｃｒ的ＰＫＩＭｅｓｓａｇｅ， ＰＫＩＨｅａｄｅｒ包含以下信息：ｐｖｎｏ是１； ＧＢ／Ｔ １９７７１－２００５ｍｅｓ ｓａｇｅＴｉｍｅ当前精确到秒时间；ｓｅｎｄｅｒ请求者的可辨别名或电子邮件地址； ｒ ｅｃｉｐｉｅｎｔ ＣＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ用来保护该消息的签名算法的算法标识符。ＰＫＩＢｏｄｙ是ＰＫＣＳ１０Ｃｅｒｔ ＲｅｇＭｅｓｓａｇｅｓ类型，此类型是一个ｃｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｌｎｆｏ， ｓｉｇｎａ－ｔ ｕｒｅＡｌｇｏｒｉｔｈｍ和ｓｉｇｎａｔｕｒｅ的序列。ｃｅｒｔｉｆｉｃａｔｉｏｎＲｅｑｕｅｓｔｉｎｆｏ包含以下信息：ｖｅｒｓｉ ｏｎ是Ｖ３ （２）；ｓｕｂｊ ｅｃｔ当且仅当ｓｅｒｉａｌ为零时才出现，指明证书持有者的可辨别名；ｓ ｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ指明了新证书的公钥和相应的算法标识符。ｓ ｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍ字段包含用来生成ｓｉｇｎａｔｕｒｅ字段的私钥的相应算法标识符；签名是对ＤＥＲ编码后的ｃｅｒｔｆｉ ｃａｔｉｏｎＲｅｑｕｅｓｔＩｎｆｏ进行的。ＰＫＩＰｒｏｔｅｃｔｉ ｏｎ字段包含一个请求者用从ＲＡ获得的秘密信息生成的一个值。实体用ＲＡ提 供的密钥产生一个ＭＡＣ． ｐｒｏｔｅｃｔｉｏｎＡｌｇ字段应为所用的消息认证算法的ＯＩＤ，并且ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ的值就是消息认证码。ＰＫＩＰｒｏｔｅｃｔｉｏｎ的输人是如下数据结构的ＤＥＲ编码：ＰｒｏｔｅｃｔｅｄＰａｒｔ：：＝ＳＥＱＵＥＮＣＥ｛ ｈｅａｄｅｒ ＰＫＩＨｅａｄｅｒ， ｂｏｄｙ ＰＫＩＢｏｄｙ｝ｂ）从ＣＡ到证书申请者的ＰＫＣＳ证书请求响应ＣＡ会返回一个包含ＰＫＩ Ｂｏｄｙ元素ｃｐ的ＰＫＩＭｅｓｓａｇｅ给证书持有者。ＰＫＩＨｅａｄｅｒ包含以下信息： ｐｖｎｏ是１； ｍｅｓ ｓａｇｅＴｉｍｅ当前精确到秒的时间；ｓｅｎｄｅｒ ＣＡ的可辨别名； ｒｅｃｉｐｉｅｎｔ证书请求头消息中的ｓｅｎｄｅｒ的值；ｐｒ ｏｔｅｃｔｉｏｎＡＩｇ用来保护该消息的签名算法的算法标识符。如果ＰＫＣＳＲｅ ｑ中有ｔｒａｎｓａｃｔｉｏｎＩＤ，则响应的ＰＫＩＨｅａｄｅｒ中应包含相同的ｔｒａｎｓａｃｔｉｏｎＩＤｏＰＫＩ Ｂｏｄｙ的元素是一个ＣｅｒＲｅｐＭｅｓｓａｇｅ类型的ｃｐ。若ＣＡ发放了证书，ＰＫＩＢｏｄｙ将包含以下信息： ｓｔａｔｕｓ为ｇｒａｎｔｅｄ或ｇｒａｎｔｅｄＷｉｔｈｍｏｄｓ，ｃｅｒｔ ｉｆｉｃａｔｅ包含新的ＧＢ／Ｔ １６２６４． ８－２００５证书。 若ｐ１０ｃｒ消息中指定了特定的密钥标识符，证书将在ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ字段包含该密钥标识符。如果没有指明具体的密钥标识符， ＣＡ将用主体公钥的低９６位ＳＨＡ－１散列函数作为ｓｕｂｊ ｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ字段中的Ｋｅｙｌｄｅｎｔｉｆｉｅｒ。散列函数是对证书中主体公钥字段的值（不包括标签和长度）计算得到的。 如果ｓ ｔａｔｕｓ为ｇｒａｎｔｅｄ或ｇｒａｎｔｅｄＷｉｔｈｍｏｄｓ， ｆａｉｌｌｎｆｏ将不出现；若ＣＡ拒绝请求，正文将包含以下信息： ｓｔ ａｔｕｓ为ｒｅｊｅｃｔｅｄ；ｆ ａｉｌｌｎｆｏ包含相应的错误代码： ．ｂａｄＡｌｇ指明算法的标识符不被识别或不被支持，因此ＣＡ无法验证签名，今ｂａ ｄｐｏｐ指明ｐｋＩＯｃｒ的ｓｉｇｎａｔｕｒｅ字段的签名被校验，但是不匹配，令ｂａ ｄＭｅｓｓａｇｅＣｈｅｃｋ指明ＰＫＩＭｅｓｓａｇｅ的ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段里的ＭＡＣ被拒绝，．ｂａ ｄｒｅｑｕｅｓｔ指明响应者不允许或不支持请求，．ｂａ ｄｔｉｍｅ指明消息头中的ｍｅｓｓａｇｅＴｉｍｅ字段中的时间与响应者的系统时间差别ＧＢ／Ｔ １９７７１－２００５太大； 哟ｅｃｔ若ｓｔａｔｕｓ字段为ｒｅｄ， ｃｅｒｔｉｆｉｔａｔｅ字段将不出现。证书还要包括以下扩展： 一个ｓｕｂｊ ｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ字段； 在ｃｅｒｔｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ字段中至少包括一个证书策略ＯＩＤ；一个ａｕｔ ｈｏｒｉｔｙ密钥标识符，包括一个Ｋｅｙｌｄｅｎｔｉｆｉｅｒ字段。若ｃ ｒ消息中还包括除ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ以外的其他扩展，ＣＡ就可以修改或忽略请求扩展。 如果颁发者的证书或是ＣＲＬｓ不提供Ｘ． ５００目录服务，证书就应含有ｉｓｓｕｅｒＡｌｔＮａｍｅ扩展中的ＵＲＬｓ以及ＣＲＬＤｉ ｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展中的ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段包含ＣＡ的签名，在消息头和消息体的ＤＥＲ编码序列上签名。６．６．７撤销请求证书持有者可以请求撤销自己的证书。证书持有者产生一个ＲｅｖＲｅｑ消息，对该消息进行签名并 发送给相应ＲＡ，并在ＲＡ审查通过用户的身份后向ＣＡ发出相应撤销信息。该签名必须用未过期、未被撤销的签名证书的相应私钥产生（可以是要撤销的证书）ｏ ＲｅｖＲｅｑ消息要标识出想撤销的证书以及要撤销的原因。ＣＡ回应ＲＡ一个ＲｅｖＲｅｐ消息，ＲＡ再回应证书持有者相应的ＲｅｖＲｅｐ消息。如果消息ｒ ｒ （ＲｅｖＲｅｑ）中包含ｔｒａｎｓａｃｔｉｏｎｌＤ，则ＣＡ和ＲＡ所响应的ｒｐ （ＲｅｖＲｅｐ）消息中也应包含相同的ｔｒａｎｓａｃｔｉｎｌＤ，注意其中从证书持有者所发出的ｒｒ和ＲＡ所发出的ｒｒ消息中的ｔｒａｎｓａｃｔｉｎｌＤ可以不同。ｒｐ消息至少要包含ｓｔａｔｕｓ字段以反映请求的状态和ｒｅｖＤｅｔａｉｌｓ字段以表示欲撤销的证书。ａ）从证书持有者到ＲＡ的撤销请求 证书持有者生成一个包含一个ＰＫＩ Ｂｏｄｙ元素ｒｒ的ＰＫＩＭｅｓｓａｇｅｏ ＰＫＩＨｅａｄｅｒ包含以下信息：ｐｖｎｏ是１； ｔｒａｎｓａｃｔｉｏｎＩＤ与终端实体名一起唯一标识一个终端实体与ＲＡ之间事务的整数；ｍｅｓ ｓａｇｅＴｉｍｅ为当前精确到秒的时间；ｓｅｎｄｅｒ为证书持有者的可辨别名； ｒｅｃｉ ｐｉｅｎｔ为ＲＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ为保护消息而使用的签名算法标识符。 消息的正文ＰＫＩＢｏｄｙ为ＲｅｖＲｅｇＣｏｎｔｅｎｔ， ＲｅｖＲｅｇＣｏｎｔｅｎｔ是ＲｅｖＤｅｔａｉｌｓ的序列。ＲｅｖＤｅｔａｉｌｓ是由Ｃｅｒｔ Ｄｅｔａｉｌｓ和三个可选字段组成的序列：原因标志；怀疑或丢失的日期和时间；以及 ｃｒＩＥｎｔｒｙＤｅｔａｉｌｓ（一个ＣＲＬ Ｅｎｔｒｙ扩展的序列）。ＣｅｒｔＤｅｔａｉｌｓ被定义为一个ＣｅｒｔＴｅｍｐｌａｔｅ。在本标准中， ＲｅｖＲｅｇＣｏｎｔｅｎｔ是一个ＲｅｖＤｅｔａｉｌｓ的序列。ＣｅｒｔＤｅｔａｉｌｓ，最少包括以下信息：ｓｅｒｉ ａｌ证书序列号；ｉ ｓｓｕｅｒ证书发放者的标识名。或是 ｓｕｂｊ ｅｃｔ证书持有者的标识名；ｉ ｓｓｕｅｒ证书发放者的标识名。Ｃｅｒ ｔＤｅｔａｉｌｓ还可在ｅｘｔｅｎｓｉｏｎｓ字段中包含一个ｓｕｂｊｅｃｔＫｅｙｌｄｅｎｔｉｆｉｅｒｏ（如果请求者希望撤销颁发给某个主体的所有证书，Ｃｅｒｔ Ｄｅｔａｉｌｓ就应仅含有ｓｕｂｊｅｃｔ和ｉｓｓｕｅｒ。也就是说，仅希望撤销单个证书的请求就只含有相应的序列号或是ｓ ｕｂｊｅｃｔＫｅｙｌｄｅｎｔｉｆｉｅｒ）。ＲｅｖＤｅｔａｉ ｌｓ要包括带有ｒｅａｓｏｎＣｏｄｅ扩展的ｃｒｌＥｎｔｒｙＤｅｔａｉｌｓ，也可以包括ｉｎｖａｌｉｄｉｔｙＤａｔｅ扩展 来说明何时该证书作废。原因代码也可以不是ｒｅｍｏｖｅＦｒｏｍＣＲＩ．，ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段含有请求者的签名，即对头和正文的ＤＥＲ编码进行签名。终端实体要用相应ＣＡ所颁发的当前有效签名证书的相应私钥进行签名。 ＧＢ／Ｔ １９７７１－２００５ｂ）从ＲＡ到ＣＡ的撤销请求 ＲＡ或证书持有者生成一个包含一个ＰＫＩＢｏｄｙ元素ｒｒ的ＰＫＩＭｅｓｓａｇｅｏ ＰＫＩＨｅａｄｅｒ包含以下信息： ｐｖｎｏ是１； ｔｒａｎｓａｃｔｉｏｎｌＤ标识ＲＡ名一起唯一标识一个ＲＡ与ＣＡ之间事务的整数；ｍｅ ｓｓａｇｅＴｉｍｅ为当前精确到秒的时间；ｓｅｎｄｅｒ为ＲＡ的可辨别名； ｒ ｅｃｉｐｉｅｎｔ为ＣＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ为保护消息而使用的签名算法标识符。 消息体与从证书持有者到ＲＡ的撤销请求相同。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ字段含有ＲＡ的签名，即对头和正文的ＤＥＲ编码进行签名。ＲＡ要用相应ＣＡ所颁发的当前有效签名证书的相应私钥进行签名。 ｃ）从ＣＡ到ＲＡ的撤销响应ＣＡ返回一个含有ＰＫＩ Ｂｏｄｙ元素ｒｐ的ＰＫＩＭｅｓｓａｇｅ给请求者。ＰＫＩＨｅａｄｅｒ包含以下信息： ｐｖｎｏ是１；ｔｒａｎｓａｃｔｉ ｏｎｌＤ和从ＲＡ到ＣＡ的撤销请求ｒｒ消息中的ｔｒａｎｓａｃｔｉｏｎｌＤ字段一样； ｍｅｓｓａｇｅＴｉｍｅ为当前精确到秒的时间；ｓ ｅｎｄｅｒ为ＣＡ的可辨别名； ｒｅｃｉｐｉｅｎｔ为ＲＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ为保护消息而使用的签名算法标识符。如果相应从ＲＡ到ＣＡ的撤销请求中有ｓｅｎｄｅｒＮ ｏｎｃｅ，则响应的ＰＫＩＨｅａｄｅｒ中应把它作为ｒｅｃｉ ｐＮｏｎｃｅ。ＰＫＩ Ｂｏｄｙ是ＲｐＣｏｎｔｅｎｔ，如果ＣＡ撤销了证书，正文将包含以下信息： ｓｔａｔｕｓ是ｇｒａｎｔｅｄ或是ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ；ｒｅｖＤｅｔ ａｉｌｓ将包含已撤销证书的ＣｅｒｔＩｄ； 如果ｓｔａｔｕｓ是ｇｒａｎｔｅｄ或ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ， ｆａｉｌｌｎｆｏ字段也可以不出现。如果ＣＡ拒绝了请求，正文就要包括如下信息： ｓｔ ａｔｕｓ为ｒｅｊｅｃｔｅｄ； ｆａｉｌｌｎｆｏ包含相应的失败代码：．ｂａｄＡｌ ｇ指明ＣＡ不能验证签名，因为算法的标识符不被识别或不被支持，令ｂａｄＭｅｓ ｓａｇｅＣｈｅｃｋ指明ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段里的签名得到验证，但是不匹配，令ｂａｄＲｅ ｑｕｅｓｔ字段指明响应者不允许或不支持请求，令ｂａｄＴｉ ｍｅ字段指明消息头中的ｍｅｓｓａｇｅＴｉｍｅ字段中的时间与响应者的系统时间差别太大， 令ｂａｄＣｅｒｔＩＤ表明ＣｅｒｔＤｅｔａｉｌｓ中的信息无法确定一个未过期、未撤销的证书；对于能够确定有问题的证书， ｒｅｖＤｅｔａｉｌｓ将包含这个被拒绝撤销证书的ＣｅｒｔＩｄ。ＰＫＩＰｒｏｔｅｃ－ｔｉ ｏｎ字段包含ＣＡ的签名，即对头和正文的ＤＥＲ编码进行签名。若ＣＡ生成ＣＲＬｓ，并且撤销请求被接受， ＣＲＬ将有以下值： ｕｓｅｒＣｅｒｔｉｆｉｃａｔｅ字段中的被撤销证书的序列号；ｒ ｅｖｏｃａｔｉｏｎＤａｔｅ收到撤销请求的日期和时间；ｃ ｒｌＥｎｔｒｙＥｘｔｅｎｓｉｏｎｓ要出现并包括：令Ｒｅｖ Ｄｅｔａｉｌｓ字段中的：ｅａｓｏｎＣｏｄｅ，除非ＣＡ的策略有专门规定，今（可选的）ＲｅｖＤｅｔ ａｉｌｓ字段中的ｂａｄＳｉｎｃｅＤａｔｅ扩展可以是ｉｎｖａｌｉｄａｉｔｙＤａｔｅ ｏＧＢ／Ｔ １９７７１－２００５ｄ）从ＲＡ到证书持有者的撤销响应 ＲＡ在收到ＣＡ的回应消息后，返回一个含有ＰＫＩＢｏｄｙ元素ｒｐ的ＰＫＩＭｅｓｓａｇｅ给证书持有者。 ＰＫＩＨｅａｄｅｒ包含以下信息：ｐｖｎｏ是１； ｔ ｒａｎｓａｃｔｉｏｎｌＤ和从ＲＡ到ＣＡ的撤销请求ｒｒ消息中的ｔｒａｎｓａｃｔｉｏｎｌＤ字段一样；ｍｅｓ ｓａｇｅＴｉｍｅ为当前精确到秒的时间；ｓｅｎｄｅｒ为ＣＡ的可辨别名； ｒ ｅｃｉｐｉｅｎｔ为ＲＡ的可辨别名；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ为保护消息而使用的签名算法标识符。 如果相应的从证书持有者到ＲＡ的撤销请求消息中有ｓｅｎｄｅｒＮｏｎｃｅ，则响应的ＰＫＩＨｅａｄｅｒ中应把它作为ｒｅ ｃｉ ｐＮｏｎｃｅ。 ＰＫＩＢｏｄｙ是ＲｐＣｏｎｔｅｎｔ，内容与从ＣＡ到ＲＡ的撤销响应相同，ＰＫＩＰｒｏｔｅｃｔｉｏｎ字段包含ＲＡ的签名，即对头和正文的ＤＥＲ编码进行签名。 ６．６．８集中产生密钥对和密钥管理证书申请拥有当前有效证书的ＰＫＩ实体可以向该证书的签发ＣＡ提出申请，申请产生加密密钥对并签发相 应的证书。下面以ＲＳＡ为例说明申请过程，在国内应用时，应使用国家密码管理主管部门审核批准的相关算法。发出申请的实体：产生临时的密钥管理密钥； 生成ＰＫＩ ｃｒ（证书申请ｃｅｒｔｉｆｉｃａｔｅ ｒｅｑｕｅｓｔ）消息，申请ＲＳＡ密钥管理证书，ｃｒ消息中包括了上一步的临时密钥；利用当前有效证书的对应私钥， 对消息进行签名；发送给ＣＡｏ 如果ＣＡ的ＣＰＳ支持集中产生加密密钥对，则ＣＡ执行如下操作：ＣＡ按申请消息的要求产生密钥对，签发密钥管理证书； 申请消息使用临时ＲＳＡ密钥； ＣＡ产生对称密钥；利用对称密钥加密新产生的私钥； 使用临时ＲＳＡ公钥加密对称密钥； ｆ产生和返回ｃｐ（ｃｅｒｔｉｉｃａｔｅ ｒｅｓｐｏｎｓｅ证书响应）消息给证书持有者。ｃｐ消息中包括了新生成的证书和加密后的私钥，或者是事务失败的代码。 ａ）集中产生密钥对申请证书持有者产生证书申请消息： ＰＫＩＭｅｓｓａｇｅ消息中的ＰＫＩＢｏｄｙ部分是ｃｒ元素。ＰＫＩＨｅａｄｅｒ 包括了如下信息：ｐｖｎｏ是１； ｍｅｓｓａｇｅＴｉ ｍｅ是当前时间，精确到秒；ｓｅｎｄｅｒ是证书持有者的可辨别名； ｒｅｃｉ ｐｉｅｎｔ是ＣＡ的可辨别名； ｐｒｏｔｅｃｔｉｏｎＡｌｇ是用于保护消息签名算法ＩＤ．消息体是Ｃｅｒ ｔＲｅｇＭｅｓｓａｇｅｓ，是一个或者多个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ组成的序列。对于集中产生密 钥对申请和密钥管理证书事务，ＣｅｒｔＲｅｇＭｅｓｓａｇｅｓ只能是包括了一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ的序列。在消息ＣｅｒｔＲｅｇＭｅｓｓａｇｅ中包括了如下信息： ｃ ｅｒｔＲｅｑ包含了申请者要求包括在证书中的各种信息。ＧＢ／Ｔ １９７７１－２００５ ｃｅｒｔＲｅｑ是ＣｅｒｔＲｅｑｕｅｓｔ， ＣｅｒｔＲｅｑｕｅｓｔ是由一个ｃｅｒｔＲｅｇＩＤ、一个ｃｅｒｔＴｅｍｐｌａｔｅ和ｃｏｎｔｒｏｌｓ所组成的序列。对于集中产生密钥对申请和密钥管理证书事务： ｃ ｅｒｔＲｅｇＩＤ是任意整数；ｃｅｒｔＴｅｍｐｌ ａｔｅ是一个ＣｅｒｔＴｅｍｐｌａｔｅ；ｃｏｎｔｒｏｌ ｓ包含了ｐｒｏｔｏｃｏｌＥｎｃｒＫｅｙ控制。ｐｒｏｔｏｃｏｌＥｎｃｒＫｅｙ ｒｅｇｉｓｔｒａｔｉｏｎ ｃｏｎｔｒｏｌ的值是临 时公钥的值和参数（如果需要），以及算法ＯＩＤ．Ｃｅ ｒｔＴｅｍｐｌａｔｅ包含了如下信息：ｖｅｒｓｉ ｏｎ必须是ｖ３（２）； ｐｕｂｌｉｃＫｅｙ指明了算法和可选的参数，说明了所申请的密钥。Ｃｅｒ ｔＴｅｍｐｌａｔｅ中可能包括了如下信息： ｓｉｇｎｉｎｇＡｌｇ指明了首选的签名算法。如果没有ｓｉ ｇｎｉｎｇＡｌｇ，则ＣＡ应该使用ｐｒｏｔｅｃｔｉｏｎＡｌｇ中说明的签名算法。申请消息里面不应该包括如下信息： ｉ ｓｓｕｅｒＵＩＤ； ｓｕｂｊｅｃｔＵＩＤ，ＰＫＩＰｒｏｔｅｃｔｉ ｏｎ域是使用当前有效证书的对应私钥对消息头和消息体的ＤＥＲ编码信息的签名 结果。ｂ）集中产生密钥对回应ＣＡ返回密钥更新（ＰＫＩ Ｍｅｓｓａｇｅ， ＰＫＩＢｏｄｙ是ｃｐ元素）消息给证书持有者。ＰＫＩＨｅａｄｅｒ包括了如下信息： ｐｖｎｏ是１； ｍｅｓｓａｇｅＴｉｍｅ是当前时间，精度到秒；ｓ ｅｎｄｅｒ是ＣＡ的可辨别名；ｒｅｃｉ ｐｉｅｎｔ是证书持有者的可辨别名，也就是ｃｒ消息的ｓｅｎｄｅｒ；ｐｒ ｏｔｅｃｔｉｏｎＡｌｇ是用于保护消息签名算法ＩＤｏ如果在ｃｒ消息中具有‘ ｒａｎｓｔｉｏｎＩＤ，则ＣＡ回应消息的消息头中包括同样的ｔｒａｎｓｔｉｏｎＩＤ。如果在ｓｅｎｄｅｒＮ ｏｎｃｅ消息中具有ｓｅｎｄｅｒＮ ｏｎｃｅ，则ＣＡ回应消息的消息头中应该包括同样的ｒｅｃｉｐ－Ｎｏｎｃｅ ｏＰＫＩ Ｂｏｄｙ是ｃｐ元素。也就是ＣｅｒｔＲｅｐＭｅｓｓａｇｅ格式。如果ＣＡ签发了新证书，在消息体中应包括如下信息： ｓｔａｔｕｓ是ｇｒａｎｔｅｄ或者是ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ；ｃｅｒｔ ｉｆｉｃａｔｅ包括了新签发的ＧＢ／Ｔ １６２６４． ８－２００５证书；ｃ ｅｒｔｉｆｉｅｄＫｅｙＰａｉ：必须存在。 ｃｅｒｔｉｆｉｅｄＫｅｙＰａｉ：将在ｃｅｒｔＯｒＥｎｃＣｅｒｔ域中包括证书，在ｐｒｉｖａｔｅＫｅｙ域中包括加密过的私钥。申请者使用临时ＲＳＡ公钥， ｐｒｉｖａｔｅＫｅｙ域应该包括ｓｙｍｍＡｌｇ，ｅｎｃＳｙｍｍＫｅｙ和ｅｎｃＶａｌｕｅａ ｓｙｍｍＡｌｇ应该包括ｔＤＥＡ－ｅｃｂ的ＯＩＤ， ｋｅｙｉｎｇ０ｐｔｉｏｎ应该是ｏｐｔｉｏｎ－２（表示Ｋ１和Ｋ２是独立产生的，Ｋ３＝Ｋ１）； ｅｎｃ ＳｙｍｍＫｅｙ是对ＣＡ产生的对称密钥的加密计算结果，使用临时ＲＳＡ公钥进行加密；对称密钥Ｋ１和Ｋ２，应串接为ＴｗｏＫｅｙｓ，见（６． ２． ２． ５） ； ＴｗｏＫｅｙｓ应该按照ＲＦＣ ２３１３说明的ＲＳＡ加密方法进行加密；加密结果编码为ｅ ｎｃＳｙｍｍＫｅｙ。加密结果编码为ＢＩＴ ＳＴＲＩＮＧ， ＢＩＴ ＳＴＲＩＮＧ的最高位就是加密结果的最高位。 新的用户证书应该包括如下扩展： ＧＢ／Ｔ １９７７１－２００５ ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ域；在ｃｅｒｔ ｉｆｉｃａｔｅＰｏｌｉｃｉｅｓ字段中至少包含一个证书策略ＯＩＤ；在Ｋｅｙｌ ｄｅｎｔｉｆｉｅ：域中有一个机构密钥标识符。ＣＡ应该对证书公钥信息计算低９６ｂｉ ｔ的ＳＨＡ－１摘要值，并将其作为ｓｕｂｊｅｃｔＫｅｙＩｄｅｎｔｉｆｉｅｒ的 值。摘要值是对证书中的主体公钥进行计算得到的，不包括标签和长度。如果。ｒ消息中包含了扩展， ＣＡ有可能修改或者忽略其扩展。 如果ｉｓｓｕｅｒ的证书和ＣＲＬ不能够从已知的Ｘ． ５００目录中得到，则新证书中应该在ｉｓｓｕｅｒＡｌｔ－Ｎａｍｅ中包括ＵＲＬｓ信息，在ＣＲＬＤｉ ｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ控制中包括ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ域。 如果ｓｔａｔｕｓ是ｇｒａｎｔｅｄ或者ｇｒａｎｔｅｄＷｉｔｈＭｏｄｓ，则ｆａｉｌＩｎｆｏ域不存在。如果ＣＡ拒绝用户的申请，消息体包括如下信息： ｓｔ ａｔｕｓ是ｒｅｊｅｃｔｅｄ；ｆ ａｉｌｌｎｆｏ包括了合适的代码，可以是： 令ｂａｄＡｌｇ表示ＣＡ不支持或者不认识ｋｒ指定的签名算法，今ｂａｄＰｏｐ表示ｐｏｐｏＳｉ ｇｎｉｎｇＫｅｙ域中的签名有误，令ｂａｄＭｅｓ ｓａｇｅＣｈｅｃｋ表示ＰＫＩＰｒｏｔｅｃｔｉｏｎ域中的签名有误，．ｂａｄＲｅｑｕｅｓ ｔ表示回应者不支持或者不允许该事务，．ｂａｄＴｉ ｍｅ表示消息头中的ｍｅｓｓａｇｅＴｉｍｅ的时间和回应者的系统时间相差太大，令ｂａｄＣｅ ｒｔｌｄ表示证书序号不能是ｓｅｒｉａｌ域中所填的非零值；如果ｓｔ ａｔｕｓ是ｒｅｊｅｃｔｅｄ， ｃｅｒｔｉｆｃａｔｅ域不存在。ＰＫＩ Ｐｒｏｔｅｃｔｉｏｎ域包含了ＣＡ对于消息头和消息体的ＤＥＲ编码的签名。ｃ）确认消息 收到ｃｐ的时候，证书持有者应该产生ＰＫＩＣｏｎｆｉｒｍ消息。ＰＫＩＨｅａｄｅｒ中的信息和利用ＲＡ向ＣＡ申请证书的情况下的ＰＫＩＨｅａｄｅｒ一致，除了ｍｅｓｓａｇｅＴｉ ｍｅ是当前时间。ＰＫＩＰｒｏｔｅｃｔ ｉｏｎ是证书持有者使用当前有效证书的对应私钥，对于消息头和消息体的ＤＥＲ编码的签名。 ６．６．９组合证书申请 签名密钥证书和密钥管理密钥证书的申请可以由一次事务完成。ＲＡ发起的注册请求和自我注册请求（见６． ６． ２，６． ６． ３，６． ６． ４ ）可以和加密证书申请组合在一起（见６．６．９）。在这样的情况下，Ｃｅｒ－ｔＲｅｇＭｅｓｓａｇｅｓ包括了两个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ的序列。一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ等同于ＲＡ发起的注册请求和自我注册请求的情况，另一个ＣｅｒｔＲｅｇＭｅｓｓａｇｅ等同于加密证书申请的情况。消息使用了签名证书申请的方式来加以保护。如果组合申请中包括的是自我注册请求， 则要么签名密钥证书申请成功，要么两个证书的申请都不成功。如果还需要额外的信息来提供ＰＯＰ，申请者则使用自我注册请求中的私钥来对消息做签名。签名密钥的ｐｏｐ将使用ｐｏｐ域来实现（见６．６．２， ６．６．３和６． ６． ６ ）。集中产生密钥对申请，私钥应该使用６． ６． ８中描述的方式进行加密。ＣＡ的响应按照响应部分的说明。ＣＡ响应可以是组成一个ＣｅｒｔＲｅｐＭｅｓｓａｇｅ，或者是分开。申请者使用ＣｅｒｔＲｅｇＩＤ来区分ＣＡ的响应。响应消息的ＰＫＩ ＦｒｅｅＴｅｘｔ域可以用来提供额外的信息。 收到ｋｐ的时候，证书持有者应该产生ＰＫＩＣｏｎｆｉｒｍ消息。ＰＫＩＨｅａｄｅｒ中的信息和利用ＲＡ向ＣＡ申请证书的情况下的ＰＫＩＨｅａｄｅｒ一致，除了ｍｅｓｓａｇｅＴｉｍｅ是当前时间。如果签名证书申请成功， ＰＫＩＰｒｏｔｅｃｔｉｏｎ是证书持有者使用新的签名证书的对应私钥，对于消息头和消息体的ＤＥＲ编码的签名。如果申请被拒绝，ＰＫＩＰｒｏｔｅｃｔｉｏｎ包含了对于消息头和消息体的ＤＥＲ编码的ｍａｃ，该ｍａｃ由认证证书请求的共享秘密产生。（如果申请因为ｂａｄＭｅｓｓａｇｅＣｈｅｃｋ被拒绝，则ＰＫＩＣｏｎｆｉｒｍ消息不需要再产生了。）ＧＢ／Ｔ １９７７１－２００５６．６．１０从资料库请求证书实体可以使用ＬＤＡＰ Ｖ２见ＲＦＣ ２５５９）向资料库请求证书。当使用ＬＤＡＰ时，实体可以通过ＬＤＡＰ搜索请求（定义见ＲＦＣ ２５５９）从资料库中请求证书，或是利用给定的ＬＤＡＰ ＵＲＬ（见ＲＦＣ１９５９）来请求证书（即ａｕｔｈｏｒｉｔｙＩｎｆｏｒｍａｔｉｏｎＡｃｃｅｓｓ扩展）。６．６．１１从资料库请求ＣＲＬ 实体可以使用ＬＤＡＰ Ｖ２（见ＲＦＣ ２５５９）向资料库请求ＣＲＬｓ。实体可以使用ＬＤＡＰ（见ＲＦＣ１７７７）从资料库中请求ＣＲＬｓ。当使用ＬＤＡＰ时，实体可以通过ＬＤＡＰ搜索请求（定义见ＲＦＣ ２５５９和ＲＦＣ１７７７）从资料库中请求ＣＲＬｓ，或是利用给定的ＬＤＡＰ ＵＲＩ，（见ＲＦＣ１９５９）来请求ＣＲＬｓ（即，ｃＲＩ．Ｄ－ｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔｓ扩展中的ｄｉｓｔｒｉｂｕｔｉｏｎＰｏｉｎｔ字段）。ＧＢ／Ｔ １９７７１－２００５附录Ａ （规范性附录） Ｘ． ５０９ ｖ３证书ＡＳＮ． １ＡｕｔｈｅｎｔｉｃａｔｉｏｎＦｒａｍｅｗｏｒｋ ｛ｐｏｉｎｔ－ｉｓｏ－ｃｃｉｔｔ ｄｓ（５） ｍｏｄｕｌｅｓ（１） ａｕｔｈｅｎｔｉｃａｔｉｏｎＦｒａｍｅｗｏｒｋ（７） ２｝ＤＥＦＩＮＩＴＩＯＮＳ：：＝ＢＥＧＩＮ一ＥＸＰＯＲＴＳ Ａｌｌ一一Ｔｈｅ ｔｙｐｅｓ ａｎｄ ｖａｌｕｅｓ ｄｅｆｉｎｅｄ ｉｎ ｔｈｉｓ ｍｏｄｕｌｅ ａｒｅ ｅｘｐｏｒｔｅｄ ｆｏｒ ｕｓｅ ｉｎ ｔｈｅ ｏｔｈｅｒ ＡＳＮ． ｌ一ｍｏｄｕｌｅｓ ｃｏｎｔａｉｎｅｄ ｗｉｔｈｉｎ ｔｈｅ Ｄｉｒｅｃｔｏｒｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ，ａｎｄ ｆｏｒ ｔｈｅ ｕｓｅ ｏｆ ｏｔｈｅｒ ａｐｐｌｉｃａｔｉｏｎｓ一ｗｈｉｃｈ ｗｉｌｌ ｕｓｅ ｔｈｅｍ ｔｏ ａｃｃｅｓｓ Ｄｉｒｅｃｔｏｒｙ ｓｅｒｖｉｃｅｓ． Ｏｔｈｅｒ ａｐｐｌｉｃａｔｉｏｎｓ ｍａｙ ｕｓｅ ｔｈｅｍ ｆｏｒ一ｔｈｅｉｒ ｏｗｎ ｐｕｒｐｏｓｅｓ， ｂｕｔ ｔｈｉｓ ｗｉｌｌ ｎｏｔ ｃｏｎｓｔｒａｉｎ ｅｘｔｅｎｓｉｏｎｓ ａｎｄ ｍｏｄｉｆｉｃａｔｉｏｎｓ ｎｅｅｄｅｄ ｔｏ一ｍａｉｎｔａｉｎ ｏｒ ｉｍｐｒｏｖｅ ｔｈｅ Ｄｉｒｅｃｔｏｒｙ ｓｅｒｖｉｃｅ．ＩＭＰＯＲＴＳｉｄ－ａｔ，ｉｎｆｏｒｍａｔｉｏｎＦｒａｍｅｗｏｒｋ， ｕｐｐｅｒＢｏｕｎｄｓ ｓｅｌｅｃｔｅｄＡｔｔｒｉｂｕｔｅＴｙｐｅｓ， ｂａｓｉｃＡｃｃｅｓｓＣｏｎｔｒｏｌＦＲＯＭ ＵｓｅｆｕｌＤｅｆｉｎｉｔｉｏｎｓ ｛ｊｏｉｎｔ－ｉｓｏ－ｃｃｉｔｔ ｄｓ（５） ｍｏｄｕｌｅｓ（１）ｕｓｅｆｕｌＤｅｆｉｎｉｔｉｏｎｓ（Ｏ ２｝Ｎａｍｅ， ＡＴＴＲＩＢＵＴＥＦＲＯＭ ＩｎｆｏｒｍａｔｉｏｎＦｒａｍｅｗｏｒｋ ｉｎｆｏｒｍａｔｉｏｎＦｒａｍｅｗｏｒｋｕｂ－ｕｓｅｒ－ｐａｓｓｗｏｒｄＦＲＯＭ ＵｐｐｅｒＢｏｕｎｄｓ ｕｐｐｅｒＢｏｕｎｄｓＡｕｔｈｅｎｔｉｃａｔｉｏｎＬｅｖｅｌＦＲＯＭ ＢａｓｉｃＡｃｃｅｓｓＣｏｎｔｒｏｌ ｂａｓｉｃＡｃｃｅｓｓＣｏｎｔｒｏｌＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒＦＲＯＭ ＳｅｌｅｃｔｅｄＡｔｔｒｉｂｕｔｅＴｙｐｅｓ ｓｅｌｅｃｔｅｄＡｔｔｒｉｂｕｔｅＴｙｐｅｓ；一ｔｙｐｅｓ一Ｃｅｒｔｉｆｉｃａｔｅ：：＝ＳＩＧＮＥＤ｛ＳＥＱＵＥＮＣＥ｛ｖｅｒｓｉｏｎ巨０］ Ｖｅｒｓｉｏｎ ＤＥＦＡＵＬＴ ｖ１，ｓｅｒｉａｌＮｕｍｂｅｒ ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａｌＮｕｍｂｅｒ，ｓｉｇｎａｔｕｒｅ Ａ１ｇｏｒｉｔｈｍｌｄｅｎｔｉｆｉｅｒ，ｉｓｓｕｅｒ Ｎａｍｅ，ｖａｌｉｄｉｔｙ Ｖａｌｉｄｉｔｙ，ｓｕｂｊｅｃｔ Ｎａｍｅ，ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙ１ｎｆｏ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏ｝ｉｓｓｕｅｒＵｎｉｑｕｅｌｄｅｎｔｉｆｉｅｒ ［１］ ＩＭＰＬＩＣＩＴ ＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，－－－ｉｆ ｐｒｅｓｅｎｔ， ｖｅｒｓｉｏｎ ｍｕｓｔ ｂｅ ｖ１ ｏｒ ｖ２－－ｓｕｂｊｅｃｔＵｎｉｑｕｅｌｄｅｎｔｉｆｉｅｒ仁２］ ＩＭＰＬＩＣＩＴ Ｕｎｉｑｕｅ］ ｄｅｎｔｉｆｉｅｒ ＯＰＴＩＯＮＡＬ，－－－ｉｆ ｐｒｅｓｅｎｔ，ｖｅｒｓｉｏｎ ｍｕｓｔ ｂｅ ｖ１ ｏｒ ｖ２－－ｅｘｔｅｎｓｉｏｎｓ ［３］ Ｅｘｔｅｎｓｉｏｎｓ ＯＰＴＩＯＮＡＬ－－ｉｆ ｐｒｅｓｅｎｔ，ｖｅｒｓｉｏｎ ｍｕｓｔ ｂｅ ｖ３－－｝Ｖｅｒｓｉｏｎ：：＝ＩＮＴＥＧＥＲ｛ＶＩＭ，ｖ２ （１），ｖ３（２）｝ＣｅｒｔｉｆｉｃａｔｅＳｅｒｉａＩＮｕｍｂｅｒ：：＝ＩＮＴＥＧＥＲ