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