組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：徐孜駿（happygogo    happygogo@sina.com）
譯文發(fā)布時(shí)間：2001-7-3
版權(quán)：本中文翻譯文檔版權(quán)歸中國(guó)互動(dòng)出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。


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證書請(qǐng)求消息格式
（Internet X.509 Certificate Request Message Format）

此備忘錄的狀況
此文檔為因特網(wǎng)社區(qū)詳細(xì)描述了一個(gè)因特網(wǎng)標(biāo)準(zhǔn)途徑協(xié)議，并且請(qǐng)求改善的討論和建
議。為了確保此協(xié)議的標(biāo)準(zhǔn)化狀態(tài)，請(qǐng)參考當(dāng)前版本的因特網(wǎng)官方協(xié)議標(biāo)準(zhǔn)（STD1）。本備
忘錄的發(fā)布是不受限制的。

版權(quán)通知
    版權(quán)所屬因特網(wǎng)社會(huì)（1999），保留全部權(quán)力。
目錄
1 摘要	2
2 略讀	2
3 證書請(qǐng)求信息(CertReqMessage)的語(yǔ)法	2
4 擁有私鑰的證明(POP)	3
4．1 簽名密鑰	3
4．2 加密密鑰	3
4．3 協(xié)議密鑰	4
4．4 POP語(yǔ)法	4
5 CertRequest語(yǔ)法	6
6  Controls語(yǔ)法	7
6．1 注冊(cè)號(hào)（Registration Token）控制	7
6．2 鑒定者（Authenticator）控制	7
6．4 文檔選項(xiàng)（Archive Options）控制	8
6．5 舊證書ID（OldCert ID）控制	9
6．6 協(xié)議加密密鑰（Protocol Encryption Key）控制	9
7 對(duì)象標(biāo)識(shí)符（Object Identifiers）	10
8 對(duì)于安全的考慮	10
9 參考	10
10 謝辭	11
附錄A． 構(gòu)造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 摘要
    本文描述了證書請(qǐng)求消息格式(CRMF)。它被用來(lái)向CA傳遞一個(gè)產(chǎn)生X.509證書請(qǐng)求
(可能通過(guò)RA)。請(qǐng)求消息一般包括公鑰和有關(guān)的登記信息。

2 略讀
    證書請(qǐng)求構(gòu)成的步驟如下：
1)	產(chǎn)生CertRequest值，其值包括：公鑰，所有或部分的終端實(shí)體（EE）的名字，其他所
要求的證書值域，以及與登記過(guò)程相連系的控制信息。
2)	可以通過(guò)計(jì)算CertRequest的值來(lái)證明擁有與所請(qǐng)求的證書的公鑰相連系的私鑰，即可
計(jì)算出POP（proof of possession，擁有私鑰的證明）的值。
3)	以上兩項(xiàng)所需要的其他登記信息，這些信息和POP值，CertRequest結(jié)構(gòu)組成證書請(qǐng)求
信息。
4)	證書請(qǐng)求信息被秘密傳遞給CA，傳遞的方法不是本文敘述的范圍。

3 證書請(qǐng)求信息(CertReqMessage)的語(yǔ)法
    證書請(qǐng)求信息由證書請(qǐng)求，一個(gè)可選的檢驗(yàn)項(xiàng)，以及一個(gè)可選的登記信息項(xiàng)。

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

 CertReqMsg ::= SEQUENCE { 
    certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL,
    -- 其內(nèi)容依賴于密鑰類型
    regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }

POP用來(lái)證明證書請(qǐng)求者確實(shí)擁有所對(duì)應(yīng)的私鑰。此項(xiàng)可由certReq計(jì)算出來(lái)，其內(nèi)容和結(jié)
構(gòu)隨公鑰算法的類型和運(yùn)作模式的改變而改變。regInfo 項(xiàng)僅包括與證書請(qǐng)求有關(guān)的補(bǔ)充信
息。它還可包括請(qǐng)求者的聯(lián)系信息，布告信息，或?qū)ψC書請(qǐng)求有用的輔助信息。直接與證書
內(nèi)容有關(guān)的信息應(yīng)該包括在certReq中。然而若RA包含另外的certReq內(nèi)容，這可以使pop
項(xiàng)無(wú)效。因此其余證書想要的數(shù)據(jù)可以由regInfo提供。

4 擁有私鑰的證明(POP)
    為了防止某些攻擊以及允許CA/RA 檢驗(yàn)終端實(shí)體和密鑰對(duì)之間對(duì)應(yīng)的有效性，PKI管
理操作使終端實(shí)體有能力證明擁有(也就是說(shuō)能用)與證書公鑰所對(duì)應(yīng)的私鑰。CA/RA在證書
交換中可自由選擇如何實(shí)施POP（例如帶外的方法或CRMF的帶內(nèi)的方法），也就是說(shuō)這可
以是一個(gè)策略問(wèn)題。然而，因?yàn)楝F(xiàn)在有許多非PKIX的操作協(xié)議在使用（例如許多電子郵件
協(xié)議），它們并不檢驗(yàn)終端實(shí)體和私鑰之間的對(duì)應(yīng)性，這要求CA/RA必須通過(guò)一些方法來(lái)實(shí)
施POP。這種對(duì)應(yīng)性僅能被CA/RA假設(shè)為已證實(shí)，直到普遍存在可操作的協(xié)議（如簽名，
加密，協(xié)議密鑰對(duì)），這樣才能證明對(duì)應(yīng)性的存在。因此若CA/RA沒(méi)有證實(shí)對(duì)應(yīng)性，在英特
網(wǎng)PKI中的證書將沒(méi)有意義。
    依照證書所要求的密鑰類型，POP可用不同方法實(shí)現(xiàn)。若密鑰可用于多種目的（如RSA
密鑰），那么POP可用任何一種方式實(shí)現(xiàn)。
    本文考慮到POP被CA或RA或兩者都驗(yàn)證的情況。一些策略可能要求CA在認(rèn)證過(guò)程
中檢驗(yàn)POP。在此過(guò)程中，RA必須提交CertRequest和POP給CA，并且作為一種選擇也
可以檢驗(yàn)POP。若策略不要求CA檢驗(yàn)POP，那么RA應(yīng)該提交終端實(shí)體的請(qǐng)求和證明給
CA。如果這不可能的話（例如，RA用帶外的方法檢驗(yàn)POP），那么RA可以向CA證明所
要求的證明已經(jīng)被驗(yàn)證。若CA使用帶外的方法證明POP（例如人工傳遞CA所生成私鑰），
那么POP項(xiàng)不會(huì)被用。

4．1 簽名密鑰
    對(duì)簽名密鑰來(lái)說(shuō)，終端實(shí)體用簽名來(lái)證明擁有私鑰。

4．2 加密密鑰 
    對(duì)加密密鑰來(lái)說(shuō)，終端實(shí)體提供私鑰給CA/RA，或?yàn)榱俗C明擁有私鑰被要求解密。解
密通過(guò)直接或間接來(lái)完成。直接的方法是RA/CA發(fā)布一個(gè)隨機(jī)測(cè)試，終端實(shí)體被要求立即
做出回答。間接的方法是發(fā)布一個(gè)被加密的證書，讓終端實(shí)體來(lái)證明它有能力對(duì)證書解密。
CA發(fā)布的證書使用一種僅能被指定終端實(shí)體使用的格式。

4．3 協(xié)議密鑰 
    對(duì)協(xié)議密鑰來(lái)說(shuō)，終端實(shí)體使用4.2節(jié)中的3種方法來(lái)加密密鑰。對(duì)于直接和間接的方
法，為了證明終端實(shí)體擁有私鑰（也就是對(duì)加密的證書解密或?qū)Πl(fā)布的測(cè)試做出回答），終
端實(shí)體和PKI管理機(jī)構(gòu)（即CA/RA）必須建立一個(gè)共享的密鑰。注意：這并不需要任何限
制強(qiáng)加在被CA鑒定的密鑰上，特別是對(duì)于Diffie-Hellman密鑰，終端實(shí)體可自由選擇它的
算法參數(shù)，例如必要時(shí)CA能產(chǎn)生一個(gè)帶有正確參數(shù)的短期密鑰對(duì)（如一次性密鑰對(duì)）。
    終端實(shí)體也可以MAC（與密鑰有關(guān)的單向散列函數(shù)稱為MAC，即消息鑒別碼）證書請(qǐng)
求（使用共享的由Diffie-Hellman算法計(jì)算出的密鑰）作為第四個(gè)可選擇的事物來(lái)證明POP。
只要CA已經(jīng)有了DH證書，這個(gè)證書已經(jīng)被終端實(shí)體知道，并且終端實(shí)體愿意使用CA的
DH參數(shù)，這個(gè)選項(xiàng)就可以使用。

4．4 POP語(yǔ)法
    ProofOfPossession ::= CHOICE {
       raVerified        [0] NULL,
       -- 用于是否RA已經(jīng)證明請(qǐng)求者擁有私鑰
       signature         [1] POPOSigningKey,
       keyEncipherment   [2] POPOPrivKey,
       keyAgreement      [3] POPOPrivKey }
這個(gè)選項(xiàng)可以使用
   POPOSigningKey ::= SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }
       --簽名signature（使用algorithmIdentifier所指的算法）是基于poposkInput 的DER
編碼值。
       --注意：如果certReq中的 CertTemplate結(jié)構(gòu)包含主體和公鑰值，那么
       --poposkInput必須省略掉，并且signature必須通過(guò)certReq 的DER編碼值計(jì)算出來(lái)。
       --如果certReq中的CertTemplate結(jié)構(gòu)沒(méi)有包含主體和公鑰值，poposkInput必須存在
       --并被簽名。
       --這種策略保證了公鑰不會(huì)同時(shí)存在于poposkInput和certReq中的 CertTemplate結(jié)
構(gòu)。

   POPOSigningKeyInput ::= SEQUENCE {
       authInfo            CHOICE {
           sender              [0] GeneralName,
           --用于當(dāng)存在一個(gè)被證實(shí)的sender的標(biāo)識(shí)符時(shí)（例如一個(gè)來(lái)自于以前頒發(fā)并且
現(xiàn)在
           --仍有效的證書的DN（可辨認(rèn)名））
           publicKeyMAC        PKMACValue },
           --用于當(dāng)現(xiàn)在不存在一個(gè)被證實(shí)的sender的GeneralName時(shí)；
--publicKeyMAC包括一個(gè)基于密碼的消息鑒別碼（MAC），
--它是基于publicKey的DER編碼值。
       publicKey           SubjectPublicKeyInfo }  

PKMACValue ::= SEQUENCE {
      algId  AlgorithmIdentifier,
      --算法是基于密碼的MAC {1 2 840 113533 7 66 13}，參數(shù)為PBMParameter。
      value  BIT STRING }

POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,
       --此項(xiàng)含有擁有私鑰的證明，并且此項(xiàng)包括私鑰本身（被加密）。
       subsequentMessage [1] SubsequentMessage,
       dhMAC             [2] BIT STRING }
       --僅用于協(xié)議密鑰，在此項(xiàng)中證明擁有私鑰，此項(xiàng)包括一個(gè)基于來(lái)自終端實(shí)體的私
有的
       --DH鑰和CA的公共的DH鑰的密鑰的MAC（基于certReq的參數(shù)的DER編碼值，
它
       --必須都包括subject和公鑰）；dhMAC必須根據(jù)附錄A中的說(shuō)明計(jì)算出來(lái)。

SubsequentMessage ::= INTEGER {
       encrCert (0),
       --要求結(jié)果證書為了終端實(shí)體被加密，接著POP將被一個(gè)確認(rèn)消息所證實(shí)
       challengeResp (1) }
       --要求為了證明擁有私鑰，CA/RA參與進(jìn)和終端實(shí)體之間的回答挑戰(zhàn)的交流。
      含有此規(guī)格的協(xié)議若要成為一個(gè)完整的協(xié)議將包括確認(rèn)和回答挑戰(zhàn)的消息。

4．4．1 基于密碼的MAC的使用
    當(dāng)publicKeyMAC被用于POPOSigningKeyInput中來(lái)證明請(qǐng)求的真實(shí)性，下述的算法將
被使用。

PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         --使用單向函數(shù)的算法標(biāo)識(shí)符（建議使用SHA-1算法)
         iterationCount      INTEGER,
         --OWF被應(yīng)用的次數(shù)
         mac                 AlgorithmIdentifier
         -- MAC的算法標(biāo)識(shí)符 (例如 DES-MAC, Triple-DES-MAC [PKCS11],
   }   -- 或 HMAC [RFC2104, RFC2202])

    使用PBMParameter來(lái)計(jì)算publicKeyMAC，由此來(lái)證明公鑰證書請(qǐng)求來(lái)源的過(guò)程可以
由兩部分組成。第一部分使用共享的秘密信息來(lái)生成一個(gè)MAC密鑰。第二部分散列公鑰，
并用MAC密鑰來(lái)產(chǎn)生一個(gè)確認(rèn)值。
    第一部分算法的初始化假設(shè)存在一個(gè)共享的分布在一個(gè)可信任的位于CA/RA和終端實(shí)
體之間的方式的秘密。salt 值被加之與此共享的秘密，并使用iterationCount次單向散列函
數(shù)。這樣，此共享的秘密作為第一次輸入，接下來(lái)每一次重復(fù)計(jì)算中，上一次的輸出作為這
一次的輸入，最后產(chǎn)生密鑰K。
    在第二部分中，K和公鑰作為輸入來(lái)產(chǎn)生publicKeyMAC，如下所示：
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )，opad、ipad定義于
RFC2104。
    單向散列函數(shù)的算法標(biāo)識(shí)符是SHA-1 {1 3 14 3 2 26}，MAC的算法標(biāo)識(shí)符是
HMAC-SHA1 {1 3 6 1 5 5 8 1 2}。

5 CertRequest語(yǔ)法
      CertRequest由請(qǐng)求標(biāo)識(shí)符、證書內(nèi)容模板和一組可選的控制信息組成。

CertRequest ::= SEQUENCE { 
    certReqId     INTEGER,          -- 使請(qǐng)求和回答相匹配的標(biāo)識(shí)符
    certTemplate  CertTemplate,   -- 所發(fā)布證書的選擇域
    controls      Controls OPTIONAL }   -- 有關(guān)證書發(fā)布的屬性信息


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 } --至少存在一個(gè)

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

6  Controls語(yǔ)法
    證書請(qǐng)求的產(chǎn)生可以包括一個(gè)或多個(gè)有關(guān)請(qǐng)求過(guò)程的控制值。

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

    以下的控制被定義為：regToken，authenticator，pkiPublicationInfo，pkiArchiveOptions，
oldCertID， protocolEncrKey（這些項(xiàng)被認(rèn)為可以超時(shí)擴(kuò)展）。

6．1 注冊(cè)號(hào)（Registration Token）控制
    regToken控制包含以前的信息（或是基于秘密的評(píng)估或是基于了解的信息），這些信息
往往被CA用于在頒發(fā)證書前驗(yàn)證請(qǐng)求者身份。一收到包含regToken的證書請(qǐng)求，CA就驗(yàn)
證這些信息，以便確認(rèn)在證書請(qǐng)求中的聲稱的身份。
    RegToken可以被CA生成，并在帶外提供給訂戶，或者對(duì)CA和訂戶都可用。任何帶
外的交換的安全性應(yīng)該足夠應(yīng)付如CA接受了某人的干擾信息而沒(méi)有接受原本訂戶的信息
這樣的冒險(xiǎn)。
    RegToken控制將典型的僅被用于終端實(shí)體進(jìn)入PKI的初始化上，而authenticator控制
（見6．2節(jié)）將不僅用于初始化，而且將用于接下來(lái)的證書請(qǐng)求上。
    在一些使用例子中，regToken可能是一個(gè)文本字符串或是一個(gè)數(shù)，如隨機(jī)數(shù)。這個(gè)值接
下來(lái)能被作為二進(jìn)制數(shù)或是一個(gè)二進(jìn)制數(shù)的字符串表示來(lái)編碼。不管數(shù)的屬性，為了確保值
的統(tǒng)一的編碼，regToken的編碼將用UTF8。

6．2 鑒定者（Authenticator）控制
    Authenticator 控制包含一些用于行為基礎(chǔ)的信息，這些信息用來(lái)在和CA交流中產(chǎn)生非
密碼的身份檢查。例子有：母親未婚時(shí)的名字，社會(huì)安全號(hào)的最后4個(gè)數(shù)字，或其他和訂戶
的CA共享的知識(shí)信息；這些信息的散列；或其他用于該目的的信息。Authenticator控制值
可由CA或訂戶生成。
    在一些使用例子中，Authenticator可能是一個(gè)文本字符串或是一個(gè)數(shù)，如隨機(jī)數(shù)。這個(gè)
值接下來(lái)能被作為二進(jìn)制數(shù)或是一個(gè)二進(jìn)制數(shù)的字符串表示來(lái)編碼。不管數(shù)的屬性，為了確
保值的統(tǒng)一的編碼，Authenticator的編碼將用UTF8。

6．3 頒發(fā)信息（Publication Information）控制
      pkiPublicationInfo控制使訂戶可以控制CA證書的發(fā)布。它被定義為如下語(yǔ)法：

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

          -- 如果action是"dontPublish"，pubInfos必須不存在。
          -- (如果action是"pleasePublish"，并且pubInfos被刪除，
          -- action被設(shè)為"dontCare" 。）

   SinglePubInfo ::= SEQUENCE {
         pubMethod    INTEGER {
             dontCare    (0),
             x500        (1),
             web         (2),
             ldap        (3) },
         pubLocation  GeneralName OPTIONAL }
    如果選擇dontPublish項(xiàng)，請(qǐng)求者指示PKI不要發(fā)布證書（這表示請(qǐng)求者要自己發(fā)布證
書）。
    如果選擇dontCare項(xiàng)，或者如果PKIPublicationInfo控制被從請(qǐng)求中刪除，請(qǐng)求者指示
PKI可以用任何它選擇的方法發(fā)布證書。
    如果請(qǐng)求者除了希望CA能夠在其他存放處使證書有效，還希望證書至少出現(xiàn)在一些地