rfcrfc2511.txt

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

方，那就要为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?[e-mail]%

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=[e-mail]%