draft-ietf-pkix-rfc2511bis-05.txt

PKIX的RFC英文文档

   Suite 6734
   9800 Savage Road
   Fort Meade, MD 20755

   EMail: [e-mail]





















Myers, et. al.             Expires May 2003                    [Page 13]


Internet Draft                                                  May 2001


Appendix A. Constructing "dhMAC"

   This Appendix describes the method for computing the bit string
   "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie-
   Hellman certificate requests.

   1. The entity generates a DH public/private key-pair.

       The DH parameters used to calculate the public SHOULD be those
       specified in the CA's DH certificate.

       From CA's DH certificate:
          CApub = g^x mod p   (where g and p are the established DH
                               parameters and x is the CA's private
                               DH component)
       For entity E:
          DH private value = y
          Epub = DH public value = g^y mod p

   2. The MACing process will then consist of the following steps.

   a) The value of the certReq field is DER encoded, yielding a binary
      string. This will be the 'text' referred to in [HMAC], the data to
      which HMAC-SHA1 is applied.

   b) A shared DH secret is computed, as follows,
                      shared secret = Kec = g^xy mod p

      [This is done by the entity E as CApub^y and by the CA as Epub^x,
      where CApub is retrieved from the CA's DH certificate and Epub is
      retrieved from the actual certification request.]

   c)  A key K is derived from the shared secret Kec and the subject and
      issuer names in the CA's certificate as follows:

      K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName)

      where "|" means concatenation.  If subjectName in the CA
      certificate is an empty SEQUENCE then DER-encoded-subjectAltName
      should be used instead; similarly, if issuerName is an empty
      SEQUENCE then DER-encoded-issuerAltName should be used instead.

   d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as:
         SHA1(K XOR opad, SHA1(K XOR ipad, text))








Myers, et. al.             Expires May 2003                    [Page 14]


Internet Draft                                                  May 2001

      where,
         opad (outer pad) = the byte 0x36 repeated 64 times
      and
         ipad (inner pad) = the byte 0x5C repeated 64 times.


      Namely,

         (1) Append zeros to the end of K to create a 64 byte string
             (e.g., if K is of length 16 bytes it will be appended with
             48 zero bytes 0x00).
         (2) XOR (bitwise exclusive-OR) the 64 byte string computed in
             step (1) with ipad.
         (3) Append the data stream 'text' to the 64 byte string
             resulting from step (2).
         (4) Apply SHA1 to the stream generated in step (3).
         (5) XOR (bitwise exclusive-OR) the 64 byte string computed in
             step (1) with opad.
         (6) Append the SHA1 result from step (4) to the 64 byte string
             resulting from step (5).
         (7) Apply SHA1 to the stream generated in step (6) and output
             the result.

          Sample code is also provided in [RFC2104, RFC2202].

   e) The output of (d) is encoded as a BIT STRING (the value "dhMAC").

   3. The proof-of-possession process requires the CA to carry out
      steps (a) through (d) and then simply compare the result of step
      (d) with what it received as the "dhMAC" value. If they match then
      the following can be concluded.

       1) The Entity possesses the private key corresponding to the
          public key in the certification request (because it needed the
          private key to calculate the shared secret).

       2) Only the intended CA can actually verify the request (because
          the CA requires its own private key to compute the same shared
          secret).  This helps to protect from rogue CAs.

References

   [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.

Acknowledgements

   The details of this Appendix were provided by Hemma Prafullchandra.

Myers, et. al.             Expires May 2003                    [Page 15]


Internet Draft                                                  May 2001



Appendix B. Use of RegInfo for Name-Value Pairs

   The "value" field of the id-regInfo-utf8Pairs 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 a UTF8STRING 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






Myers, et. al.             Expires May 2003                    [Page 16]


Internet Draft                                                  May 2001



   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"):






Myers, et. al.             Expires May 2003                    [Page 17]


Internet Draft                                                  May 2001


   <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]%

References

   [RFC1738]  Berners-Lee, T., Masinter, L. and M.  McCahill,
             "Uniform Resource Locators (URL)", RFC 1738, December 1994.





Myers, et. al.             Expires May 2003                    [Page 18]


Internet Draft                                                  May 2001


Appendix C. ASN.1 Structures and OIDs

PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
     -- Directory Authentication Framework (X.509)
        Version, AlgorithmIdentifier, Name, Time,
        SubjectPublicKeyInfo, Extensions, UniqueIdentifier
           FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
               id-pkix1-explicit-88(1)}

     -- Certificate Extensions (X.509)
        GeneralName
           FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
                  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                  id-pkix1-implicit-88(2)}

     -- Cryptographic Message Syntax
        EnvelopedData
           FROM CryptographicMessageSyntax { iso(1) member-body(2)
                us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
                modules(0) cms(1) };

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

CertReqMsg ::= SEQUENCE {
    certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL,
    -- content depends upon key type
    regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }

CertRequest ::= SEQUENCE {
    certReqId     INTEGER,          -- ID for matching request and reply
    certTemplate  CertTemplate,  -- Selected fields of cert to be issued
    controls      Controls OPTIONAL }   -- Attributes affecting issuance