方，那就要為pubInfos設置兩個SinglePubInfo值，一個是x500、web或ldap，另一個是
dontCare。
    如果pubLocation被用的話，此項表示請求者愿意證書在這些地方被發現（注意，
GeneralName可包括例如URL和IP地址等）。

6．4 文檔選項（Archive Options）控制
    pkiArchiveOptions控制使訂戶能夠應用這樣的信息，這些信息用于建立一個對應于證書
請求公鑰的私鑰的文檔。它的語法定義如下：

PKIArchiveOptions ::= CHOICE { 
      encryptedPrivKey     [0] EncryptedKey,
      -- 私鑰的實際值
      keyGenParameters     [1] KeyGenParameters,
      -- 使私鑰能夠重新生成的參數
      archiveRemGenPrivKey [2] BOOLEAN }
-- 如果sender 希望receiver保存receiver對應請求所生成的密鑰對中的私鑰，則設為
真。
-- 如果不要被保存，則設為假。


EncryptedKey ::= CHOICE { 
      encryptedValue        EncryptedValue,
      envelopedData     [0] EnvelopedData }
      -- 加密私鑰必須被放在envelopedData中


EncryptedValue ::= SEQUENCE { 
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
-- 被加密的值被使用的意指的算法
symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
      -- 用于加密值的對稱算法
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- 用于加密值的對稱密鑰（已加密）
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
      -- 用于加密對稱密鑰的算法
      valueHint     [4] OCTET STRING         OPTIONAL,
      -- 一個有關encValue內容的簡單的描述或標識符（它可能只對發送終端有意義，
      -- 并且只有EncryptedValue 以后可以被發送終端重新檢驗，它才可以用）
      encValue       BIT STRING }


KeyGenParameters ::= OCTET STRING 

    一種發送密鑰的選擇是發送有關如何使用KeyGenParameters選項重新產生密鑰的信息
（例如，對許多RSA實行來說，可以發送第一個最初測試的隨機數）。對于這個參數的實際
的語法可以定義在這個文檔的接下來版本中，或定義在另一個標準中。

6．5 舊證書ID（OldCert ID）控制
    如此項存在，則OldCertID詳述了被當前證書請求所更新的證書。其語法為：

CertId ::= SEQUENCE {
         issuer           GeneralName,
         serialNumber     INTEGER
     }

6．6 協議加密密鑰（Protocol Encryption Key）控制
    如此項存在，則protocolEncrKey詳述了一個CA用于加密對CertReqMessages的回答的
密鑰。此項能被用于當CA有發送給訂戶的需要加密的信息。這些信息中包括一個由CA生
成的讓訂戶使用的私鑰。protocolEncrKey的編碼應為SubjectPublicKeyInfo。

7 對象標識符（Object Identifiers）
      id-pkix的對象標識符為：
id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
   dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

-- 用于Internet X.509 PKI 協議及其組件的部分
   id-pkip  OBJECT IDENTIFIER :: { id-pkix pkip(5) }

   -- 在CRMF中的注冊登記控制（Registration Controls）
   id-regCtrl  OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
   id-regCtrl-regToken            OBJECT IDENTIFIER ::= { id-regCtrl 1 }
   id-regCtrl-authenticator       OBJECT IDENTIFIER ::= { id-regCtrl 2 }
   id-regCtrl-pkiPublicationInfo  OBJECT IDENTIFIER ::= { id-regCtrl 3 }
   id-regCtrl-pkiArchiveOptions   OBJECT IDENTIFIER ::= { id-regCtrl 4 }
   id-regCtrl-oldCertID           OBJECT IDENTIFIER ::= { id-regCtrl 5 }
   id-regCtrl-protocolEncrKey     OBJECT IDENTIFIER ::= { id-regCtrl 6 }

   -- CRMF 中的注冊信息（Registration Info）
   id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
   id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
   -- 使用OCTET STRING
   id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
   -- 使用CertRequest

8 對于安全的考慮
    CRMF傳送的安全性是基于協議或用于和CA通信的進程的安全結構。這些協議或進程
需要確保完整性，數據來源的真實性和信息的隱私。如果一個CRMF包括敏感的訂戶信息，
并且CA有一個終端實體所知的加密證書，那么強烈建議使用CRMF加密。

9 參考
    [HMAC] Krawczyk， H.， Bellare， M.和R. Canetti，"HMAC: Keyed- Hashing for Message 
Authentication"（“HMAC：為了保證信息真實性的密鑰Hash散列”）， RFC 2104, 1997.2。

10 謝辭
    作者非常感謝Barbara Fox， Warwick Ford， Russ Housley和 John Pawling所做的貢獻。
他們的復審和建議進一步闡明和改善了本篇的實用功能。



附錄A． 構造dhMAC
    本附錄描述了計算Diffie- Hellman證書請求的POPOPrivKey結構中的dhMAC位串的方
法。

1  終端產生一個DH公/私鑰對
    用于計算公鑰的DH參數被詳述在CA的DH證書中。
    從CA的DH證書中，CApub = g^x mod p   ，這里g，p是已有的DH參數，而x是
CA私有的DH組件。
    對終端E來說，DH private value = y，Epub = DH public value = g^y mod p。

2  MAC進程有以下步驟組成
a）	    certReq項的值用DER編碼，產生一個二進制串。這就是在[HMAC]中提
到的‘text’，它是HMAC-SHA1算法所應用的數據。
b）	計算共享的DH secret，如下所示：shared secret = Kec = g^xy mod p。終端E
計算CApub^y，CApub 是來自于CA的DH證書；CA計算Epub^x，Epub是來自
于證書請求。
c）	密鑰K來自于Kec，證書請求者名稱，證書頒發者名稱。如下所示：K = 
SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)，這里‘|’的意
思是級連。如果在CA證書中subjectName為空，則替代使用
DER-encoded-subjectAltName。如果CA證書中issuerName為空，則替代使用
DER-encoded-issuerAltName。
d）	按照RFC2104來用數據'text'計算HMAC-SHA1，SHA1(K XOR opad, SHA1(K 
OR ipad, text)) ，此處opad = 0x36 重復64次，ipad = 0x5C 重復64次。也就是
說，
（1）	在K的末端填充0，來生成一個64字節的串（例如，若K為16字節長，
就要填充48個0字節）。
（2）	XOR（異或）第1步生成的64字節K和ipad。
（3）	把‘text’加到第2步生成的64字節串上。
（4）	對第3步 生成的字節串應用SHA1算法。
（5）	XOR第1步生成的64字節K和opad。
（6）	把第4步中SHA1生成的結果加到第5步生成的64字節串上。
（7）	使用SHA1算法計算第6步中的產生值，最后輸出結果。
例子代碼在RFC2104, RFC2202中有。
       e）d）的輸出被編碼為位串（"dhMAC")。

3 驗證擁有私鑰（proof-of-possession）的進程需要CA執行
    執行從a）到d），然后比較d）步的結果和CA收到的"dhMAC"值。如果它們匹配，則
有如下結論：
1）	終端擁有與證書請求中的公鑰對應的私鑰（因為終端需要私鑰來計算shared secret）。
2）	只有CA能驗證請求（CA需要自己的私鑰來計算同樣的shared secret）。這有助于防止
CA受騙。

參考文獻

   [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed
             Hashing for Message Authentication", RFC 2104, February
             1997.

   [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
             SHA-1", RFC 2202, September 1997.

謝詞
此附錄的細節由Hemma Prafullchandra所提供

Appendix B. Use of RegInfo for Name-Value Pairs

   The "value" field of the id-regInfo-utf8Pairs OCTET STRING (with
   "tag" field equal to 12 and appropriate "length" field) will contain
   a series of UTF8 name/value pairs.

   This Appendix lists some common examples of such pairs for the
   purpose of promoting interoperability among independent
   implementations of this specification.  It is recognized that this
   list is not exhaustive and will grow with time and implementation
   experience.

B.1. Example Name/Value Pairs

   When regInfo is used to convey one or more name-value pairs (via id-
   regInfo-utf8Pairs), the first and subsequent pairs SHALL be
   structured as follows:

      [name?value][%name?value]*%

   This string is then encoded into an OCTET STRING and placed into the
   regInfo SEQUENCE.

   Reserved characters are encoded using the %xx mechanism of [RFC1738],
   unless they are used for their reserved purposes.

   The following table defines a recommended set of named elements.
   The value in the column "Name Value" is the exact text string that
   will appear in the regInfo.

      Name Value
      ----------
      version            -- version of this variation of regInfo use
      corp_company       -- company affiliation of subscriber
      org_unit           -- organizational unit
      mail_firstName     -- personal name component
      mail_middleName    -- personal name component
      mail_lastName      -- personal name component
      mail_email         -- subscriber's email address
      jobTitle           -- job title of subscriber
      employeeID         -- employee identification number or string

   mailStop           -- mail stop
      issuerName         -- name of CA

      subjectName        -- name of Subject
      validity           -- validity interval

   For example:

      version?1%corp_company?Acme, Inc.%org_unit?Engineering%
      mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
      mail_email?john@acme.com%

B.1.1. IssuerName, SubjectName and Validity Value Encoding

   When they appear in id-regInfo-utf8Pairs syntax as named elements,
   the encoding of values for issuerName, subjectName and validity SHALL
   use the following syntax.  The characters [] indicate an optional
   field, ::= and | have their usual BNF meanings, and all other symbols
   (except spaces which are insignificant) outside non-terminal names
   are terminals.  Alphabetics are case-sensitive.

      issuerName  ::= <names>
      subjectName ::= <names>
      <names>     ::= <name> | <names>:<name>

      <validity>  ::= validity ? [<notbefore>]-[<notafter>]
      <notbefore> ::= <time>
      <notafter>  ::= <time>

   Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]].  HH, MM,
   and SS default to 00 and are omitted if at the and of value 00.

   Example validity encoding:

      validity?-19991231%

   is a validity interval with no value for notBefore and a value of
   December 31, 1999 for notAfter.

   Each name comprises a single character name form identifier followed
   by a name value of one or UTF8 characters. Within a name value, when
   it is necessary to disambiguate a character which has formatting
   significance at an outer level, the escape sequence %xx SHALL be
   used, where xx represents the hex value for the encoding concerned.
   The percent symbol is represented by %%.

      <name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>

   Name forms and value formats are as follows:

   X.500 directory name form (identifier "X"):

   <xname> ::= <rdns>
      <rdns>  ::= <rdn> | <rdns> , <rdn>
      <rdn>   ::= <avas>
      <avas>  ::= <ava> | <avas> + <ava>
      <ava>   ::= <attyp> = <avalue>
      <attyp> ::= OID.<oid> | <stdat>

   Standard attribute type <stdat> is an alphabetic attribute type
   identifier from the following set:

      C      (country)
      L      (locality)
      ST     (state or province)
      O      (organization)
      OU     (organizational unit)
      CN     (common name)
      STREET (street address)
      E      (E-mail address).

   <avalue> is a name component in the form of a UTF8 character string
   of 1 to 64 characters, with the restriction that in the IA5 subset of
   UTF8 only the characters of ASN.1 PrintableString may be used.

   Other name form (identifier "O"):
      <oname> ::= <oid> , <utf8string>

   E-mail address (rfc822name) name form (identifier "E"):
      <ename> ::= <ia5string>

   DNS name form (identifier "D"):
      <dname> ::= <ia5string>

   URI name form (identifier "U"):
      <uname> ::= <ia5string>

   IP address (identifier "I"):
      <iname> ::= <oid>

   For example:

      issuerName?XOU=Our CA,O=Acme,C=US%
      subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%