Suite 6734   9800 Savage Road   Fort Meade, MD 20755   EMail: dpkemp@missi.ncsc.milMyers, et. al.             Expires May 2003                    [Page 13]Internet Draft                                                  May 2001Appendix 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 2001Appendix 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 intervalMyers, 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?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"):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=john@acme.com%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 2001Appendix C. ASN.1 Structures and OIDsPKIXCRMF {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 ::=BEGINIMPORTS     -- 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 CertReqMsgCertReqMsg ::= 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