rfcrfc2511.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：徐孜骏（happygogo    [e-mail]）
译文发布时间：2001-7-3
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                                      M. Myers
Request for Comments: 2511                                                  VeriSign
Category: Standards Track                                                  C. Adams
                                                               Entrust Technologies
                                                                            D. Solo
                                                                           Citicorp
                                                                            D. Kemp
                                                                                DoD
                                                                         March 1999

X.509证书请求消息格式
（Internet X.509 Certificate Request Message Format）

此备忘录的状况
此文档为因特网社区详细描述了一个因特网标准途径协议，并且请求改善的讨论和建
议。为了确保此协议的标准化状态，请参考当前版本的因特网官方协议标准（STD1）。本备
忘录的发布是不受限制的。

版权通知
    版权所属因特网社会（1999），保留全部权力。
目录
1 摘要	2
2 略读	2
3 证书请求信息(CertReqMessage)的语法	2
4 拥有私钥的证明(POP)	3
4．1 签名密钥	3
4．2 加密密钥	3
4．3 协议密钥	4
4．4 POP语法	4
5 CertRequest语法	6
6  Controls语法	7
6．1 注册号（Registration Token）控制	7
6．2 鉴定者（Authenticator）控制	7
6．4 文档选项（Archive Options）控制	8
6．5 旧证书ID（OldCert ID）控制	9
6．6 协议加密密钥（Protocol Encryption Key）控制	9
7 对象标识符（Object Identifiers）	10
8 对于安全的考虑	10
9 参考	10
10 谢辞	11
附录A． 构造dhMAC	11
Appendix B. Use of RegInfo for Name-Value Pairs	12
Appendix C. ASN.1 Structures and OIDs	15
Full Copyright Statement	21

1 摘要
    本文描述了证书请求消息格式(CRMF)。它被用来向CA传递一个产生X.509证书请求
(可能通过RA)。请求消息一般包括公钥和有关的登记信息。

2 略读
    证书请求构成的步骤如下：
1)	产生CertRequest值，其值包括：公钥，所有或部分的终端实体（EE）的名字，其他所
要求的证书值域，以及与登记过程相连系的控制信息。
2)	可以通过计算CertRequest的值来证明拥有与所请求的证书的公钥相连系的私钥，即可
计算出POP（proof of possession，拥有私钥的证明）的值。
3)	以上两项所需要的其他登记信息，这些信息和POP值，CertRequest结构组成证书请求
信息。
4)	证书请求信息被秘密传递给CA，传递的方法不是本文叙述的范围。

3 证书请求信息(CertReqMessage)的语法
    证书请求信息由证书请求，一个可选的检验项，以及一个可选的登记信息项。

 CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg 

 CertReqMsg ::= SEQUENCE { 
    certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL,
    -- 其内容依赖于密钥类型
    regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }

POP用来证明证书请求者确实拥有所对应的私钥。此项可由certReq计算出来，其内容和结
构随公钥算法的类型和运作模式的改变而改变。regInfo 项仅包括与证书请求有关的补充信
息。它还可包括请求者的联系信息，布告信息，或对证书请求有用的辅助信息。直接与证书
内容有关的信息应该包括在certReq中。然而若RA包含另外的certReq内容，这可以使pop
项无效。因此其余证书想要的数据可以由regInfo提供。

4 拥有私钥的证明(POP)
    为了防止某些攻击以及允许CA/RA 检验终端实体和密钥对之间对应的有效性，PKI管
理操作使终端实体有能力证明拥有(也就是说能用)与证书公钥所对应的私钥。CA/RA在证书
交换中可自由选择如何实施POP（例如带外的方法或CRMF的带内的方法），也就是说这可
以是一个策略问题。然而，因为现在有许多非PKIX的操作协议在使用（例如许多电子邮件
协议），它们并不检验终端实体和私钥之间的对应性，这要求CA/RA必须通过一些方法来实
施POP。这种对应性仅能被CA/RA假设为已证实，直到普遍存在可操作的协议（如签名，
加密，协议密钥对），这样才能证明对应性的存在。因此若CA/RA没有证实对应性，在英特
网PKI中的证书将没有意义。
    依照证书所要求的密钥类型，POP可用不同方法实现。若密钥可用于多种目的（如RSA
密钥），那么POP可用任何一种方式实现。
    本文考虑到POP被CA或RA或两者都验证的情况。一些策略可能要求CA在认证过程
中检验POP。在此过程中，RA必须提交CertRequest和POP给CA，并且作为一种选择也
可以检验POP。若策略不要求CA检验POP，那么RA应该提交终端实体的请求和证明给
CA。如果这不可能的话（例如，RA用带外的方法检验POP），那么RA可以向CA证明所
要求的证明已经被验证。若CA使用带外的方法证明POP（例如人工传递CA所生成私钥），
那么POP项不会被用。

4．1 签名密钥
    对签名密钥来说，终端实体用签名来证明拥有私钥。

4．2 加密密钥 
    对加密密钥来说，终端实体提供私钥给CA/RA，或为了证明拥有私钥被要求解密。解
密通过直接或间接来完成。直接的方法是RA/CA发布一个随机测试，终端实体被要求立即
做出回答。间接的方法是发布一个被加密的证书，让终端实体来证明它有能力对证书解密。
CA发布的证书使用一种仅能被指定终端实体使用的格式。

4．3 协议密钥 
    对协议密钥来说，终端实体使用4.2节中的3种方法来加密密钥。对于直接和间接的方
法，为了证明终端实体拥有私钥（也就是对加密的证书解密或对发布的测试做出回答），终
端实体和PKI管理机构（即CA/RA）必须建立一个共享的密钥。注意：这并不需要任何限
制强加在被CA鉴定的密钥上，特别是对于Diffie-Hellman密钥，终端实体可自由选择它的
算法参数，例如必要时CA能产生一个带有正确参数的短期密钥对（如一次性密钥对）。
    终端实体也可以MAC（与密钥有关的单向散列函数称为MAC，即消息鉴别码）证书请
求（使用共享的由Diffie-Hellman算法计算出的密钥）作为第四个可选择的事物来证明POP。
只要CA已经有了DH证书，这个证书已经被终端实体知道，并且终端实体愿意使用CA的
DH参数，这个选项就可以使用。

4．4 POP语法
    ProofOfPossession ::= CHOICE {
       raVerified        [0] NULL,
       -- 用于是否RA已经证明请求者拥有私钥
       signature         [1] POPOSigningKey,
       keyEncipherment   [2] POPOPrivKey,
       keyAgreement      [3] POPOPrivKey }
这个选项可以使用
   POPOSigningKey ::= SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }
       --签名signature（使用algorithmIdentifier所指的算法）是基于poposkInput 的DER
编码值。
       --注意：如果certReq中的 CertTemplate结构包含主体和公钥值，那么
       --poposkInput必须省略掉，并且signature必须通过certReq 的DER编码值计算出来。
       --如果certReq中的CertTemplate结构没有包含主体和公钥值，poposkInput必须存在
       --并被签名。
       --这种策略保证了公钥不会同时存在于poposkInput和certReq中的 CertTemplate结
构。

   POPOSigningKeyInput ::= SEQUENCE {
       authInfo            CHOICE {
           sender              [0] GeneralName,
           --用于当存在一个被证实的sender的标识符时（例如一个来自于以前颁发并且
现在
           --仍有效的证书的DN（可辨认名））
           publicKeyMAC        PKMACValue },
           --用于当现在不存在一个被证实的sender的GeneralName时；
--publicKeyMAC包括一个基于密码的消息鉴别码（MAC），
--它是基于publicKey的DER编码值。
       publicKey           SubjectPublicKeyInfo }  

PKMACValue ::= SEQUENCE {
      algId  AlgorithmIdentifier,
      --算法是基于密码的MAC {1 2 840 113533 7 66 13}，参数为PBMParameter。
      value  BIT STRING }

POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,
       --此项含有拥有私钥的证明，并且此项包括私钥本身（被加密）。
       subsequentMessage [1] SubsequentMessage,
       dhMAC             [2] BIT STRING }
       --仅用于协议密钥，在此项中证明拥有私钥，此项包括一个基于来自终端实体的私
有的
       --DH钥和CA的公共的DH钥的密钥的MAC（基于certReq的参数的DER编码值，
它
       --必须都包括subject和公钥）；dhMAC必须根据附录A中的说明计算出来。

SubsequentMessage ::= INTEGER {
       encrCert (0),
       --要求结果证书为了终端实体被加密，接着POP将被一个确认消息所证实
       challengeResp (1) }
       --要求为了证明拥有私钥，CA/RA参与进和终端实体之间的回答挑战的交流。
      含有此规格的协议若要成为一个完整的协议将包括确认和回答挑战的消息。

4．4．1 基于密码的MAC的使用
    当publicKeyMAC被用于POPOSigningKeyInput中来证明请求的真实性，下述的算法将
被使用。

PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         --使用单向函数的算法标识符（建议使用SHA-1算法)
         iterationCount      INTEGER,
         --OWF被应用的次数
         mac                 AlgorithmIdentifier
         -- MAC的算法标识符 (例如 DES-MAC, Triple-DES-MAC [PKCS11],
   }   -- 或 HMAC [RFC2104, RFC2202])

    使用PBMParameter来计算publicKeyMAC，由此来证明公钥证书请求来源的过程可以
由两部分组成。第一部分使用共享的秘密信息来生成一个MAC密钥。第二部分散列公钥，
并用MAC密钥来产生一个确认值。
    第一部分算法的初始化假设存在一个共享的分布在一个可信任的位于CA/RA和终端实
体之间的方式的秘密。salt 值被加之与此共享的秘密，并使用iterationCount次单向散列函
数。这样，此共享的秘密作为第一次输入，接下来每一次重复计算中，上一次的输出作为这
一次的输入，最后产生密钥K。
    在第二部分中，K和公钥作为输入来产生publicKeyMAC，如下所示：
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )，opad、ipad定义于
RFC2104。
    单向散列函数的算法标识符是SHA-1 {1 3 14 3 2 26}，MAC的算法标识符是
HMAC-SHA1 {1 3 6 1 5 5 8 1 2}。

5 CertRequest语法
      CertRequest由请求标识符、证书内容模板和一组可选的控制信息组成。

CertRequest ::= SEQUENCE { 
    certReqId     INTEGER,          -- 使请求和回答相匹配的标识符
    certTemplate  CertTemplate,   -- 所发布证书的选择域
    controls      Controls OPTIONAL }   -- 有关证书发布的属性信息


CertTemplate ::= SEQUENCE { 
    version      [0] Version               OPTIONAL,
    serialNumber [1] INTEGER               OPTIONAL,
    signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
    issuer       [3] Name                  OPTIONAL,
    validity     [4] OptionalValidity      OPTIONAL,
    subject      [5] Name                  OPTIONAL,
    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
    issuerUID    [7] UniqueIdentifier      OPTIONAL,
    subjectUID   [8] UniqueIdentifier      OPTIONAL,
    extensions   [9] Extensions            OPTIONAL }

  OptionalValidity ::= SEQUENCE {
      notBefore  [0] Time OPTIONAL,
      notAfter   [1] Time OPTIONAL } --至少存在一个

  Time ::= CHOICE {
      utcTime        UTCTime,
      generalTime    GeneralizedTime }

6  Controls语法
    证书请求的产生可以包括一个或多个有关请求过程的控制值。

Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

    以下的控制被定义为：regToken，authenticator，pkiPublicationInfo，pkiArchiveOptions，
oldCertID， protocolEncrKey（这些项被认为可以超时扩展）。

6．1 注册号（Registration Token）控制
    regToken控制包含以前的信息（或是基于秘密的评估或是基于了解的信息），这些信息
往往被CA用于在颁发证书前验证请求者身份。一收到包含regToken的证书请求，CA就验
证这些信息，以便确认在证书请求中的声称的身份。
    RegToken可以被CA生成，并在带外提供给订户，或者对CA和订户都可用。任何带
外的交换的安全性应该足够应付如CA接受了某人的干扰信息而没有接受原本订户的信息
这样的冒险。
    RegToken控制将典型的仅被用于终端实体进入PKI的初始化上，而authenticator控制
（见6．2节）将不仅用于初始化，而且将用于接下来的证书请求上。
    在一些使用例子中，regToken可能是一个文本字符串或是一个数，如随机数。这个值接
下来能被作为二进制数或是一个二进制数的字符串表示来编码。不管数的属性，为了确保值
的统一的编码，regToken的编码将用UTF8。

6．2 鉴定者（Authenticator）控制
    Authenticator 控制包含一些用于行为基础的信息，这些信息用来在和CA交流中产生非
密码的身份检查。例子有：母亲未婚时的名字，社会安全号的最后4个数字，或其他和订户
的CA共享的知识信息；这些信息的散列；或其他用于该目的的信息。Authenticator控制值
可由CA或订户生成。
    在一些使用例子中，Authenticator可能是一个文本字符串或是一个数，如随机数。这个
值接下来能被作为二进制数或是一个二进制数的字符串表示来编码。不管数的属性，为了确
保值的统一的编码，Authenticator的编码将用UTF8。

6．3 颁发信息（Publication Information）控制
      pkiPublicationInfo控制使订户可以控制CA证书的发布。它被定义为如下语法：

PKIPublicationInfo ::= SEQUENCE {
        action     INTEGER {
                     dontPublish (0),
                     pleasePublish (1) },
        pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }

          -- 如果action是"dontPublish"，pubInfos必须不存在。
          -- (如果action是"pleasePublish"，并且pubInfos被删除，
          -- action被设为"dontCare" 。）

   SinglePubInfo ::= SEQUENCE {
         pubMethod    INTEGER {
             dontCare    (0),
             x500        (1),
             web         (2),
             ldap        (3) },
         pubLocation  GeneralName OPTIONAL }
    如果选择dontPublish项，请求者指示PKI不要发布证书（这表示请求者要自己发布证
书）。
    如果选择dontCare项，或者如果PKIPublicationInfo控制被从请求中删除，请求者指示
PKI可以用任何它选择的方法发布证书。
    如果请求者除了希望CA能够在其他存放处使证书有效，还希望证书至少出现在一些地