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

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

1、寸ICS 35. 100. 70 L 79 4占2-.0 共王GB/T 19714一2005言息石设.证InCormation technology Security technology Internet public key inCrastructure Certificate management protocol 2005-04-19发布中华人民共和国国家质量监督检验检菇总局中国国家标准化管理委员会2005-10-01实发布一寸可G/T 19714-2005 目次前言. . . . . . .,. . . . . . . . . . . . . E 引言. . . .,. . . .

2、. . . . . . . . . . .,. . . . . . . . H l 范围. . . . . . . . . . . . . . . . 1 2 规范性引用文件. . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 术语和定义. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 缩略语. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 PKI管理概述

3、. . . . . . . . . . . . . . . . . . . . .,. 3 5. 1 PKI管理模型. . . . . . . . ., . . . . . .,. . . . . . . . . . . . . . . . . . 3 5. 2 PKI实体的定义. . . . . . . . . . . . . . . . . . . . . . .,. . . . . .,. 3 5. 3 PKI管理要求. . . . . . . . . . ., . . . . . . . . . . . . . . . 5 5. 4 PKI管理操作. . .国. . . . . . .

4、 . . . .,. . .,. . 5 6 前提与限制. . . . . . . . .,. ., . . . . . . . . . . . 7 6. l 终端实体初始化. . . . . . 7 6. 2 初始注册/认证.7 6. 3 私钥拥有证明. . . . ., 9 6. 4 根CA的更新10 7 数据结构. 12 7. 1 PKI消息综述. . 12 7. 2 公共数据结构.16 7. 3 与操作相关的数据结构. 20 8 必需的PKI管理功能. . . . 24 8. 1 根CA初始化. 24 8. 2 根CA密钥更新. 24 8. 3 下级CA初始化. 24 8. 4 CRL

5、产生. . . . 24 8 5 PKI信息请求. 24 8. 6 交叉认证. . 24 8 7 终端实体初始化. 25 8. 8 证书请求. 26 8 9 密钥更新.26 9 传输.26 9. 1 基于文件的协议.26 9. 2 直接基于TCP的管理协议. . . . . . . 26 9. 3 基于E-mail的管理协议. . . . 27 9 4 基于HTTP的管理协议. . . . 27 附录A(资料性附录)RA存在的原因. . . 28 附录B(规范性附录)必选的PKI管理消息结构. . . . . . 29 附录C(规范性附录)可选的PKI管理消息结构. . . . . 36 I

6、GB/T 19714-2005 附录DC资料性附录)附录EC资料性附录)附录F(规范性附录附录GC资料性附录请求消息行为说明使用口令短语. . . . . . . . . . . .,. . . . . . . . . . . . . . . . . . . . . . . . . . . 可编译的ASN.l模块. . . . . . 用于耳MAIL或者HTTP的MIME类型. . . . . . . . . 参考文献 . . . . . . . . . . . . . . . .,. E 42 43 45 56 57 v 飞GB/T 19714-2005 前言本标准是依据IETFRFC 25

7、10制定的a本标准凡涉及密码算法相关内容，按国家有关法规实施。本标准中引用的RSA、SHAl，DH密码算法均为举例性说明，具体使用时均须采用国家商用密码管理委员会批准的相应算法。本标准的附录B、附录C、附录F为规范性附录，附录A、附录D、附录E、附录G为资料性附录。本标准由中华人民共和国信息产业部提出。本标准由全国信息安全标准化技术委员会一-U=-m山二据卡一时主和求。请A证认钥一南回一证=认严=始求JIJ=初请牛=皮革护一=分请保=式钥证K=方密认M=外生成用一带产生利验证请求处理请求生成认证响应. 证书确认消息一验证确认消息生成响应一一确认ack(可选的-H.那么BASEKEY的全部H比特

8、将作为密钥的前H比特.OWF (1 1 1 BASEKEY)所得结果将作为密钥的下-H比特.OWF (2 1 1 BASEKEY)所得结果将作为密钥的再下一-H比特，依此类推，直到得到所有的K比特为止。(这里，N代表数字N的ASCII字节编码，11代表串联。)注E建议PBMParameter字段在个交易的所有消息中例如ir/ip/ certConf/ pkiConO保持不变.这样可以降低计算PasswodBasedMac的负荷。非对称密钥对使用非对称密钥算法进行消息保护，下面以DH算法为例说明.当发送者和接收者拥有相容的DH参数的DH证书时，为了保护消息，终端实体必须基于自己的DH私钥值和PK

9、I消息接收方的DH公钥值产生一个对称密钥。PKIProtection将包含由这个对称密钥计算出的MAC值，protectionAlg如下sid-DHBasedMac OBJECT IDENTIFIER ,= (1 2 840 113533 7 66 30) DHBMParameter ,= SEQUENCE owf Algorithmldentifi凹，一散列函数算法ID自lacAlgorithmldenti白erMAC算法ID在上面的protectionAlg中，对D-H计算的结果应用OWF.OWF的输出(为了方便引用称作BASEKEY .其长度为H)用于形成对称密钥。如果MAC算法要求个K

10、比特的密钥而且KH.那么BASEKEY的全部H比特将作为密钥的前H比特.OWF(I11 BASEKEY)所得结果将作为密钥的下一H比特.OWF(211 BASEKEY)所得结果将作为密钥的再下-H比特，依此类推，直到得到所有的K比特为止。(这里，uN代表数字N的ASCII字节编码，II代表串联。)签名在这种情况下，发送方拥有一个签名密钥对，对PKI消息进行签名即可。PKIProtecton将包15 一一GB/T 19714-2005 7.2 d) 含签名值，protectionAlg为一种用于数字签名的算法。多重保护当终端实体发送一个保护的PKI消息JRA.RA可以追加自己的保护(可以是MAC

11、或签名，取决于RA和CA之间共亭的信息和证书)后将消息转发到CA.这种保护通过将终端实体发送的消息整个嵌套到-个新的PKI消息中实现。使用的结构如下-NestedMessageContent : = PKIMessages 公共戴据结构在定义PKIBody中的特定类型之前，我们先定义-些多处使用的数据结构。7. 2. 1 被申请的证书内容各种PKI管理消息都要求消息的发起者指明证书里存放的某些字段的值。CertTemplate结构体使得EE或者RA可以尽可能地指定它们所希望申请到的证书里的内容。CertTemplate结构体与证书的内容完全一致，但所有的字段都是可选的。注2即使消息的发起者指明

12、了它所申请的证书的所有内容.CA机构仍然可以自由改动实际发放的证书的字段值.如果申请者不能接受被修改后的证书，那么申请者必须回送一个certConf消息，其中或者不包括该证书(通过一个CertHash)，或者包吉该证书(通过-个CertHash)但同时状态置为rejected0 CertHash和certConf消息的定义以及使用参见7.3.18.CertTemplate语法见附录D及RFC2511.7.2.2 加密值在PKI消息中发送加密值(在本标准中，加密值限于私钥或者证书)时采用EncryptedValue数据结构.EncryptedValue的语法见RFC2511。使用该数据结构要求创

13、建者和期望的接收者分别都能够进行加密和解密操作。典型情况下，这意味着发送者和接收者拥有，或者能够产生共享的秘密密钥。如果PKIMessage的接收者已经拥有用于解密的私钥，则encSymmKey字段可以包含用接收者的公钥加密的会话密钥(sessionkey)。7.2.3 PKI消息的状态编码和失败信息16 所有的响应消息都包含某些状态信息。下面定义了相应的值zPKIStatus : = INTEGER accepted (0) -表示得到了所要求的数据grantedWithMods (1) -得到的数据与所要求的类似，但申请者有责任确定有无差别rejection (2). -无法得到的数据，在

14、该消息的其他地方有更多的信息waiting (3). -请求的包体尚未被处理，期望稍后将获取结果(注意z对具有该状态的响应，恰当的处理方式可以是使用3.3. 22中定义的轮询请求/响应PKIMessages;使用底层的传输层轮询机制也是一种可行的方法revocationWarning (4) , 句本消息包含一个即将作废的警告信息revocationNotification (白，-通知已经作废keyUpdateWarning (6) 一在密钥更新请求消息、中oldCertld指示的密钥已经更新响应者可以使用下列语法以提供有关失败状况的更多信息。PKIFailurelnfo : = BIT S

15、TRING ( 因为多种情况可能导致失败，所以在需要时可以加入更多的代码badAlg (0) , 一不可识别或者不支持的算法标识符badMessageCheck (1) , 完整性检查失败(例如，签名验证不成功)badRequest (2) , 不允许或不支持的交易badTime (3) , 一根据本地策略，请求中的messageTime与系统时间不够接近badCertId (4) , 一无法找到与提供的条件匹配的证书badDataFormat (5) , 一提交的数据格式错误wrongAuthority (们，一请求中指明的权威机构与本响应的创建者不同incorrectDa臼(7), -申请

16、者的数据错误(用于公证服务)missingTimeStamp (8) , ，在要求存在时戳的时候没有提供(根据策略要求badPOP (9) , -拥有证明失败PKIStatuslnfo : = SEQUENCE status statusString failInfo 7.2.4 证书标iRPKIStatus, PKIFreeText PKIFailurelnfo OPTIONAL. OPTIONAL CertId数据结构用于鉴别特寇的证书。CertId的语法见RFC2511。7.2.5 带外根证书公钥一年一._ ._一一GB/T 19714-2005 每个根CA必须能够通过一些带外方式来发布

17、它的当前公钥。虽然这样的方法不在本文描述的范围之内，我们定义了支持这种方法的数据结构。一般而言，有两种可能的方法:CA机构直接发布它的自签名证书;或者可以通过目录服务器(或其他类似方式)获得自签名证书，同时CA发布自签名证书的哈希值用于(由使用者)在使用(CA证书)之前进行完整性校验。OOBCert ,= Certificate 该证书中的值域有如下限制217 GB/T 19714-2005 一证书必须是自签名的(即，签名必须可以用Subj ectPu blicKey lnlo中的值来验证); -一主体字段和签发者字段的值必须完全相同;-一-如果主体字段为空，则主体可替换名和签发者可替换名扩展

18、项必须同时存在，并且具有完全相同的值;所有其他扩展项的值必须符合自签名证书的要求(比如，主体和签发者的密钥标识符必须完全相同。OOBCertHash : = SEQUENCE hashAlg OJ Algorithmldenti日ercertId IJ CertId hashVal BIT STRING OPTIONAL, OPTIONAL, -hashVal是对由certID所标识的自签名证书进行运算得出的值散列(哈希)值的目的在于=任何(通过带外方式)安全获取到散列(哈希)值的用户都能验证该CA的自签名证书。7.2.6 归档选项请求者可以用PKIArchiveOptions结构体来指明它们

19、希望PKI归裆某私钥。PKIArchiveOptions的语法见RFC2511.7.2.7 发布信息请求者可以用PKIPublicationlnlo结构体来指明它们希望PKI发布证书。PKIPublicationlnlo的语法见RFC2511.7.2.8 拥有证明结构体如果是为签名密钥对申请证书(即申请一个验证证书)，则可以使用POPOSigningKey结构体来证明对签名私钥的拥有。POPOSigningKey的语法见附录D及RFC2511，但注意本标准中POPOSigningKeyInput存在下面的语义约定gPOPOSigningKeylnput : = SEQUENCE authlnl

20、o CHOICE sender oJ GeneralName, -取自PKIHeader(仅当发送者的身份鉴别己通过某种方式(如以前发布的、当前处于有效状态的-证书中的DN)建立之后使用)publicKeyMAC PKMACValue )发送者当前没有己鉴别通过的通用名(GeneralName)存在时使用;publicKeyMAC包含一个-基于口令的针对公钥的DER编码的MAC值(使用PKIHeader中的protectionAlg算法标识)publicKey SubjectPublicKey lnlo 取自CertTemplate另一方面，如果为加密密钥对申请证书(即申请一个加密证书)，则可

21、以使用下列三种方式之一来证明对解密私钥的拥有。a) b) 18 通过在证书请求中包含加密后的私钥(在PKIArchiveOptions控制结构体中。CA不直接返回证书，而是返回加密后的证书(即，返回的证书用一个随机产生的对称密钥加密，而对称密钥本身用证书请求中包含的公钥来加密)一这是6.3.2中提到的间接方式。c) GB/T 19714-2005 终端实体通过使用源自该对称密钥的密钥计算PKIConfirm消息的MAC值，来向CA机构证明它拥有解密私钥。(当PKIMessage消息中包含不止一个CertReqMsg证书请求，并且每个CertReqMsg使用不同的对称密钥时，MAC计算使用源自所

22、有这些对称密钥的一个密钥。)计算MAC的操作使用7.1定义的PasswordBasedMacAlgld, 让EE在CertReqMessages和CertRepMessage之间参与挑战一响应协议使POPODecKeyChall和POPODecKeyResp消息;参照下文)一一这是6.3.2中提到的直接方式。(这种方式典型的应用环境是RA验证POp，然后代表终端实体向CA发送认证请求。在这种情况下，CA相信RA在为终端实体申请证书之前已经正确地验证了POP，)完整的协议如下所示(注意req不一定要将req封装为嵌套消息): EE RA CA req 这个MIME对象可以使用普通的MIME处理机

23、制(引擎)进行发送和接收，提供了一种利用Email传输PKIX-CMP消息的方法。具体实现可能希望识别并使用application/x-pkixcmp MIME类型(本文挡的早期版本中指定)以支持向后的兼容性。MIME对象的描述参见附录G.9, 4 基于HTTP的管理协议本条指定了一种通过HTTP协议传送上面定义的消息的DER编码的方法。一个简单的MIME对象定义如下2Content-Type, application/pkixcmp 这个MIME对象可以通过www链接使用普通的HTTP处理机制(引擎)进行发送和接收，提供了一种利用浏览器一服务器方式传输PKIX-CMP消息的方法。具体实现可能

24、希望识别并使用application/ x-pkixcmpMIME类型以支持向后的兼容性。MIME对象的描述参见附录G.27 GB/T 19714-2005 28 附录A(资料性附录)RA存在的原因RA存在的原因有技术和组织两方面。技术原因包括下述几点2一一如果使用硬件令牌，那么有可能不是所有的终端实体都有对其令牌进行初始化的设备.RA设备就必须包括相应的功能(这是一个策略问题); 有些终端实体不能发布证书，同样RA可以帮助实现这个功能;一当终端实体不能发布签名的撤销请求(如果完全丢失了密钥对)时.RA就代表与其关联的终端实体进行发布。RA存在的组织原因如下:把功能集中在RA设备中比给所有的终

25、端实体提供功能要有效得多(特别是需要用到特殊的令牌初始化设备时); 在组织内建立RA可以减少CA的数量，这在有些情况下是很重要的;RA可以更好地鉴别人们的电子名字，特别是当CA在物理上远离终端实体的情况下$一一对于很多应用，在适当的位置已经存在了管理结构，因此很容易产生RA角色(这可能不适用于CA)。GB/T 19714-2005 附录(规范性附录)必选的PKI管理消息结构B 本附录包含了遵循本标准的实现必须支持的PKI消息的详细描述(参见第8章)。在以下PKI管理操作中使用的PKIMessage的结构如下:初始的注册/认证;一基本认证方案s一一证书请求g一一密钥更新。大纲结构解释的通用规则B

26、. 1 当个人单独的大纲描述中没有可选(OPTIONAL)或缺省(DEFAULT)字段时，相关的消息中也不能有(例如g接收者可以以语法错误为由来丢弃包含这些字段的消息。如果必须强制字段具备一些很明显的值，那么文中也不会特别提及(例如s在本标准中pvno总是为2)。当结构中不止一个消息时，将分别进行描述。PKIMessage结构的algorithmldentifiers将分别描述。存在一种特殊的X.500 DN被称为NULL-DN;这表明DN包含长度为0的SEQUENCEOF RelativeDistinguishedNames(它的DER编码为3000H)。当某字段需要GeneralName，

27、但是又没有合适的值时(例如z终端实体在知道它的名字之前产生了一个请求), GeneralName就为X.500 NULL-DN (例如:CHOICE的Name字段含有NULL-DN)。这种特殊的值也称为NULL-GeneralName。当描述某大纲没有给GeneralName规定值时，相关PKIMessage字段的值就为NULL-GeneralName。这种情况通常发生在某些消息的PKIHeader的sender字段，在字段命名发生歧义的时候，描述名字就使用点号(例如:certTemplate. subject表示subJect字段在certTemplate字段中当SEQUENCEOF typ

28、es作为消息的一部分时，我们使用以0为基数的数组符号来描述SEQUENCE OF中的字段。(例如:crmO. certReq. certTemplate. subject是指请求消息中第一个certReqMsg的子字段。在第B.4-B. 6章中所有的PKI消息交换需要由发送实体发送certConf消息，同时由响应实体发送PKIConfirm消息。在某些描述大纲中，由于包体为NULL，而包头的内容参照上下文非常清楚，所以没有包括PKIConfirm，因为它的体为NULL，头内容在上下文中很清楚。对于protectionAlg可以使用任何认证方法(例如g如果知道共享的秘密信息可以使用基于口令的a)

29、 ) -hu g) ) -t i) d) e) c) f) MAC，或者签名)。算法使用参数B.2 29 表B.l包含了在PKI管理协议中使用的算法定义。GB/T 19714-2005 表B.1PKI管理协议使用的算法 Name:消息结构使用的标识符Use:算法使用的原因和地方MSG SIG ALG 用签名保护PKI消息MSG_MAC_ALG 用MAC保护PKI消息SYM PENC ALG 使用带外方式发布对称密钥时对称加密终端实体的私钥PROT_ENC_ALG 用于加密在PKIMessages中传输的(用于加密的对称密钥中的)私钥的非对称算法PROT_SYM_ALG 用于加密私钥的比特位(这

30、种类型的密钥使用PROT_ENC_ALG进行加密)的对称加密算法B.3 所有权证明大纲结构当需要证明拥有请求的证书中与验证公钥相应的签名私钥时，使用POP字段(在ProofOfPosse-SSlOn结构中的pop字段中的siEnature字段)。字段值说明algorithmldentifier MSG_SIG_ALG 这个证明只允许采用签名保护slgnature present 使用MSG_SIG_ALG计算比特位证明拥有请求的证书中与加密公钥相应的解密私钥时不按照这种结构，而是使用certConf消息的CertHash字段来代替。在带内认证请求协议中，不是每一个CA/RA都需要所有权证明(签

31、名密钥，解密密钥或密钥一致密钥).(如何进行POP基本上是一个策略问题，每一个CA都会在公布的Policy010和CertificationPractice Statement中表示清楚)。然而，本标准要求CAjRA实体把POP(通过某些方法)作为认证过程的一部分。所有的终端实体都必须能够提供POP(例如:PKIX-CMP协议的组件必须支持)。B.4 初始的注册/认证(基本认证方案)(未初始化的)终端实体向CA请求(第一个证书。当CA返回包含有证书的消息时，终端实体会发送证书确认。CA再发回PKIConfirm，关闭交易。所有的消息都进行了认证。本方案允许终端实体请求对本地产生公钥的认证(典型

32、地为签名密钥)。终端实体也可以选择请求集中产生并且认证另一个密钥对(典型地为加密密钥对。请求认证只能用于一个本地产生的公钥(对于更多的公钥，需要使用独立的PKIMessage)。终端实体必须支持对与本地产生公钥相关联的私钥的所有权证明。前提:终端实体可以验证基于带外方法的CA签名e终端实体和CA共享对称MACing密钥。消息流z步骤终端实体1 format ir PKI 2 3 4 5 6 handle ip 7 format certConf - Ir handle ir format ip certConf 9 handle certConf 10 format PKIConf 11 ge

33、nm handle genm produce genp ccr - 3 handle ccr 4 produce ccp 5 ccp 6 handle ccp ccr: 字段值sender Requesting CA name请求CA一产生消息的CA的名字reClplent Responding CA name 响应CA被要求产生证书的CA的名字messageTime time of production of message产生消息的时间请求CA的当前时间protectionAlg MSG_SIG_ALG 38 一这个请求只允许签名保护senderKID present if require

34、d 如果在要求对消息保护进行验证时需要则必须存在recipKID present if required 一如果在要求对消息保护进行验证时需要则必须存在transactionID present 一执行特定与实现相关的值，对请求CA有意义(如果已经在响应CA中使用，那么响应CA产生的一个拒绝消息)senderNonce 128比特(伪随机比特数freeText body present 任何有效值ccr (C盯tReqMessages)只允许一个CertReqMsg如果请求多重交叉证书，那么就必须打包在不同的PKIMessagecertTemplate present 一后面是细节如下verS

35、lon vl or v3 建议dsigningAlg present 一请求CA必须事先知道用什么算法来对证书签名subject present 仅在提议使用subjectAltNames扩展项时可以为NULL-DNvalidity present 一必须完全指定(例如两个字段都存在)lssuer present 仅在提议使用issuerAltNames扩展项时可以为NULL-DNpublicKey present 一需要鉴定认证的密钥(用于必须是-种签名算法的密钥extensions optionally present 请求CA必须为要求出现在交叉证书中请求的所有扩展建议取值Popoggn

36、1吨Keypresent 见第B.3章protectIOn present 一使用MSG_SIG_ALG计算比特位extraCerts optionally present 可以包含请求者想要包括的任何额外证书ccp: 字段值sender 响应CA的名字产生消息的CA的名字recipent 发起请求CA的名字被要求产生证书的CA的名字GB/T 19714-2005 、39 GBjT 19714-2005 C.7 messageTime 产生消息的时间-响应CA的当前时间protectionAlg MSG SIG ALG -这个消息只允许签名保护senderKID present if requ

37、ired ，如果在要求对消息保护进行验证的情况下时需要则必须存在recipKID present if required transactionID present 相应ccr消息中的值senderNonce present 一128比特(伪)随机数比特recipNonce present 一相应ccr消息中的senderNoncefreeText 任何有效值body ccp (CertRepMessage) 只允许个CertResponse-如果请求多个交叉证书，那么就要就必须打包在不同的PKIMessage中response present status present PKIStatus

38、lnfo. status present 如果PKlStatuslnfo.status为下面两种情况之一-accepted，或grantedWithMods一那么certI日edKeyPair必须存在，同时failInfo缺省failInfo present depending on 如果PKIStatuslnfo.status为- rejectlOn PKIStatuslnfo. status 那么certifiedKeyPair缺省，同时failInfo必须存在-而且设置了相应的比特位certifiedKeyPair present depending on PKIStatuslnfo.

39、status certificate present depending on certifiedKeyPair 在发布之前由请求CA必须检查的实际证书的内容protectlOn present 一使用MSG_SIG_ALG计算的比特位extraCerts optionally present d可以包含响应者想要包括的任何额外证书使用外部身份证书进行带内初始化(未初始化的)终端实体希望初始化为CA/PKI的一员.为了鉴别身份，它使用原来一个已经存在的由另一个(外部)CA，CA-X发布签发的身份证书。在CA-l和CA-X之间必须已经建立信任关系，这40 GB/T 19714-2005 样CA-

40、l才能使验证EE的由CA-X签名的证书生效。另外，在EE的个人安全环境(PSE)中必须建立一些机制，以便允许终端实体可以鉴别和验证由CA-l签名的PKIMessage(例如.PSE包含为CA-l公钥发布签发的证书，这个证书由终端实体信任的另一个CA在带外验证技术基础上签名，这种信任建立在带外认证技术基础上)。终端实体发送初始化请求来启动交易。当CA-l用包含新证书的消息响应时，终端实体返回证书确认。CA-l发送PKIConfirm来结束交易。所有的消息都经过签名(EE消息使用与外部身份证书中的公钥相对应的私钥来签名，CA-l消息用与EE的PSE中信任的另一个证书公钥相对应的私钥来签名)。消息交

41、互流程与B.4中的一样，但是有以下不同zEE和CA-l不共享对称MACing密钥(在这些实体之间没有带外共享的秘密信息), 一-Ir中发送者sender名字必须存在(并且与外部身份证书中对象subject名字一样h一一在所有消息的protectionAlg中必须使用MSG_SIG_ALG的protectionAlg;一一在ir的extraCer臼字段中必须携带外部身份证书;一一不使用senderKID和recipKID，body为Ir或ipp保护比特数根据protectionAlg字段来计算。41 飞GB/T 19714-2005 以下的定义来自RFC2511。附录D (资料性附录)请求消息行

42、为说明主要是为了使对请求消息中的行为更系统说明g另外，所有的语法和语义与RFC2511中的一样。42 CertRequest : = SEQUENCE certReqld INTEGER, certTemplate CertTemplate, controls Controls OPTIONAL AltCertTemplate : = AttributeTypeAndValue POPOSigningKey : = SEQUENCE poposklnput algorithmldentifier slgnature oJ POPOSigningKeylnput OPTIONAL, Algori

43、thmldentifier, BIT STRING POPOPrivKey : = CHOICE thisMessage subsequentessage dhAC oJ BIT STRING, lJ Subsequentessage， 2J BIT STRING ) 附录E (资料性附录)使用口令短语GB/T 19714-2005 撤销请求必须合并采用合适的安全机制，包括恰当的验证，用于减少拒绝服务攻击发生成功的可能性。对请求的数字签名(本标准中在支持撤销请求的情况下必须支持)能够满足验证要求，但是在某些情况下需要有替代机制(例如，私钥已经不能访问，但是终端实体希望在重新认证另一个密钥对之前

44、请求撤销)。为了满足这些情况.在本标准中，如果支持撤销请求并且在需要撤销之前请求者和响应者之间可以建立共享的秘密信息，那么要求必须支持对请求的PasswordBasedMAC(以符合给定环境的本地安全策略)。Revocation Passphrase是已经在某些环境中使用的一种机制，在这种机制中，一个足够平均的值(例如，相对长的passphrase而不是短的password)在撤销之前就在且仅在实体和CA/RA之间共享，并且在以后用于验证撤销请求。在本标准中，是否支持下列用于建立共享秘密信息(例如，revocationpassphrase)的技术是可选的。在CMP消息中的准确使用如下:OID以及在7.3.19中指定的OID以及值可在任何时间在GenMsg消息中发送，或者也可以在任何时间任何一个PKIMessage的PKIHeader的generalInfo字段中发送。(特别地，EncryptedValue可以在certConf消息头中发送EncryptedValue.certConf该消息是用于确认已经接受了在初始化请求和证书