path: root/doc/rfc/rfc4211.txt

Network Working Group                                          J. Schaad
Request for Comments: 4211                       Soaring Hawk Consulting
Obsoletes: 2511                                           September 2005
Category: Standards Track


               Internet X.509 Public Key Infrastructure
               Certificate Request Message Format (CRMF)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the Certificate Request Message Format (CRMF)
   syntax and semantics.  This syntax is used to convey a request for a
   certificate to a Certification Authority (CA), possibly via a
   Registration Authority (RA), for the purposes of X.509 certificate
   production.  The request will typically include a public key and the
   associated registration information.  This document does not define a
   certificate request protocol.





















Schaad                      Standards Track                     [Page 1]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


Table Of Contents

   1. Introduction and Terminology ....................................3
   2. Overview ........................................................3
      2.1. Changes since RFC 2511 .....................................4
   3. CertReqMessage Syntax ...........................................4
   4. Proof-of-Possession (POP) .......................................5
      4.1. Signature Key POP ..........................................7
      4.2. Key Encipherment Keys ......................................9
           4.2.1. Private Key Info Content Type ......................11
           4.2.2. Private Key Structures .............................12
           4.2.3. Challenge-Response Guidelines ......................13
      4.3. Key Agreement Keys ........................................14
      4.4. Use of Password-Based MAC .................................14
   5. CertRequest syntax .............................................16
   6. Controls Syntax ................................................18
      6.1. Registration Token Control ................................18
      6.2. Authenticator Control .....................................19
      6.3. Publication Information Control ...........................19
      6.4. Archive Options Control ...................................21
      6.5. OldCert ID Control ........................................23
      6.6. Protocol Encryption Key Control ...........................23
   7. RegInfo Controls ...............................................23
      7.1. utf8Pairs .................................................23
      7.2. certReq ...................................................24
   8. Object Identifiers .............................................24
   9. Security Considerations ........................................25
   10. References ....................................................26
      10.1. Normative References .....................................26
      10.2. Informative References ...................................27
   11. Acknowledgements ..............................................28
   Appendix A.  Use of RegInfo for Name-Value Pairs ..................29
      A.1.  Defined Names ............................................29
      A.2.  IssuerName, SubjectName, and Validity Value Encoding .....29
   Appendix B.  ASN.1 Structures and OIDs ............................32
   Appendix C.  Why do Proof-of-Possession (POP) .....................38















Schaad                      Standards Track                     [Page 2]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


1.  Introduction and Terminology

   This document describes the Certificate Request Message Format
   (CRMF).  A Certificate Request Message object is used within a
   protocol to convey a request for a certificate to a Certification
   Authority (CA), possibly via a Registration Authority (RA), for the
   purposes of X.509 certificate production.  The request will typically
   include a public key and the associated registration information.

   The certificate request object defined in this document is not a
   stand-alone protocol.  The information defined in this document is
   designed to be used by an externally defined Certificate Request
   Protocol (CRP).  The referencing protocol is expected to define what
   algorithms are used, and what registration information and control
   structures are defined.  Many of the requirements in this document
   refer to the referencing Certificate Request Protocol (CRP).

   Certificate requests may be submitted by an RA requesting a
   certificate on behalf of a Subject, by a CA requesting a cross-
   certificate from another CA, or directly by an End Entity (EE).

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document (in uppercase, as shown) are to be interpreted as
   described in RFC 2119 [RFC2119].

2.  Overview

   Construction of a certification request involves the following steps:

   a)  A CertRequest object is constructed.  This object may include the
       public key, all or a portion of the Subject name, other requested
       certificate fields, and additional control information related to
       the registration process.  Depending on the CRP, this information
       can be specified by the Subject and potentially modified by an
       RA, or specified by the RA based on knowledge of the Subject or
       documentation presented by the Subject.

   b)  If required, a proof-of-possession (of the private key
       corresponding to the public key for which a certificate is being
       requested) value is calculated.

   c)  Additional registration information can be combined with the
       proof-of-possession value and the CertRequest structure to form a
       CertReqMessage.  Additional registration information can be added
       by both the Subject and an RA.






Schaad                      Standards Track                     [Page 3]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   d)  The CertReqMessage is securely communicated to a CA.  Specific
       means of secure transport are to be specified by each CRP that
       refers to this document.

2.1.  Changes since RFC 2511

   1.  Addition of an introduction section.

   2.  Addition of the concept of a CRP and language relating to CRPs.

   3.  In section 6.2, changed regToken to authenticator.

   4.  Add information describing the contents of the EncryptedValue
       structure.

   5.  Changed name and contents of OID {id-regInfo 1}.

   6.  Added text detailing what goes into the fields of the different
       structures defined in the document.

   7.  Replaced Appendix A with a reference to [RFC2875].  The only
       difference is that the old text specified to use subject alt name
       instead of subject name if subject name was empty.  This is not
       possible for a CA certificate issued using PKIX.  It would
       however be useful to update RFC 2875 to have this fallback
       position.

   7.  Insert Appendix C describing why POP is necessary and what some
       of the different POP attacks are.

   8.  pop field in the CertReqMsg structure has been renamed to popo to
       avoid confusion between POP and pop.

   9.  The use of the EncryptedValue structure has been deprecated in
       favor of the EnvelopedData structure.

   10.  Add details on how private keys are to be structured when
       encrypted.

   11.  Allow for POP on key agreement algorithms other than DH.

3.  CertReqMessage Syntax

   A certificate request message is composed of the certificate request,
   an optional proof-of-possession field, and an optional registration
   information field.





Schaad                      Standards Track                     [Page 4]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


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

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

   The fields of CertReqMsg have the following meaning:

      certReq contains the template of the certificate being requested.
      The template is filled in by (or on behalf of) the Subject.  Not
      all fields within the template need to be specified.  Details on
      this field are found in section 5.

      popo contains the value used to demonstrate that the entity that
      will be identified as the Subject of the certificate is actually
      in possession of the corresponding private key.  This field varies
      in structure and content based on the public key algorithm and the
      mode (encryption vs. signature) in which the algorithm is used, as
      specified in the KeyUsage field of the certificate to be issued.
      Details on this field are found in section 4.

      regInfo field SHOULD contain only supplementary information
      relating to the context of the certificate request, where such
      information is required to fulfill the request.  This information
      might include subscriber contact information, billing information,
      or other ancillary information useful to fulfillment of the
      request.

   Information directly related to certificate content SHOULD be
   included in the certReq content.  However, inclusion of additional
   certReq content by RAs can invalidate the popo field (depending on
   the details of the POP method used).  Therefore, data intended for
   certificate content MAY be provided in regInfo.

   It is the responsibility of a referencing CRP to define the details
   of what can be specified in the regInfo field.  This document
   describes one method of encoding the information found in this field.
   Details on this encoding are found in Appendix A.

4.  Proof-of-Possession (POP)

   In order to prevent certain attacks (see Appendix C) and to allow a
   CA/RA to properly check the validity of the binding between a subject
   and a key pair, the PKI management structures specified here make it
   possible for a subject to prove that it has possession of (i.e., is



Schaad                      Standards Track                     [Page 5]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   able to use) the private key corresponding to the public key for
   which a certificate is requested.  A given CRP is free to choose how
   to enforce POP (e.g., out-of-band procedural means versus the CRMF
   in-band message) in its certification exchanges.  Within a given CRP,
   CAs and RAs are free to choose from among the POP methods provided
   (i.e., this is a policy issue local to an RA/CA).  A CRP SHOULD
   define either which POP methods are required, or specify a mechanism
   for clients to discover the POP methods supported.

   Any CRP referencing this document MUST enforce POP by some means.
   There are currently many non-PKIX operational protocols in use
   (various electronic mail protocols are one example) that do not
   explicitly check the binding between the end entity and the private
   key.  Until operational protocols that do verify the binding (for
   signature, encryption, and key agreement key pairs) exist, and are
   ubiquitous, this binding cannot be assumed to have been verified by
   the CA/RA.  Therefore, one cannot truly know if the binding of the
   public key and the identity in the certificate is actually correct.

   POP is accomplished in different ways depending on the type of key
   for which a certificate is requested.  If a key can be used for
   multiple purposes (e.g., a signing and decryption RSA key), then any
   of the methods MAY be used.  Protocol designers need to be aware that
   there can be hardware limitations on what POP methods may be usable,
   e.g., if the private key is maintained in a hardware token.

   This specification allows for cases where POP is validated by the CA,
   the RA, or both.  Some policies require the CA to verify POP during
   certificate issuance, in which case the RA MUST forward the end
   entity's CertRequest and ProofOfPossession fields unaltered to the
   CA.  (In this case, the RA could verify the POP and reject failing
   certificate requests rather than forwarding them to the CA.)  If the
   CA is not required by policy to verify POP, then the RA SHOULD
   forward the end entity's request and proof, unaltered, to the CA as
   above.  If this is not possible (for example because the RA verifies
   POP by an out-of-band method), then the RA uses the raVerified
   element to attest to the CA that the required proof has been
   validated.  If the CA/RA uses an out-of-band method to verify POP
   (such as physical delivery of CA/RA-generated private keys), then the
   ProofOfPossession field is omitted.

   ProofOfPossession ::= CHOICE {
       raVerified        [0] NULL,
       signature         [1] POPOSigningKey,
       keyEncipherment   [2] POPOPrivKey,
       keyAgreement      [3] POPOPrivKey }





Schaad                      Standards Track                     [Page 6]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   The fields of ProofOfPossession have the following meaning:

      raVerified indicates that the RA has performed the POP required on
      the certificate request.  This field is used by an RA when 1) the
      CA is not required to do its own POP verification and 2) the RA
      needs to change the contents of the certReq field.  CRPs MUST
      provide a method for the RA to sign the ProofOfPossession.  A
      requestor MUST NOT set this field and an RA/CA MUST NOT accept a
      ProofOfPossession where the requestor sets this field.

      signature is used for performing POP with signature keys.  The
      details of this field are covered in section 4.1.

      keyEncipherment is used for performing POP with key encipherment
      encryption based keys (i.e., RSA).  The details of this field are
      covered in section 4.2.

      keyAgreement is used for performing POP with key agreement type
      encryption keys (i.e., DH).  The details of this field are covered
      in section 4.3.

4.1.  Signature Key POP

   POP for a signature key is accomplished by performing a signature
   operation on a piece of data containing the identity for which the
   certificate is desired.

   There are three cases that need to be looked at when doing a POP for
   a signature key:

   1.  The certificate subject has not yet established an authenticated
       identity with a CA/RA, but has a password and identity string
       from the CA/RA.  In this case, the POPOSigningKeyInput structure
       would be filled out using the publicKeyMAC choice for authInfo,
       and the password and identity would be used to compute the
       publicKeyMAC value.  The public key for the certificate being
       requested would be placed in both the POPOSigningKeyInput and the
       Certificate Template structures.  The signature field is computed
       over the DER-encoded POPOSigningKeyInput structure.

   2.  The CA/RA has established an authenticated identity for the
       certificate subject, but the requestor is not placing it into the
       certificate request.  In this case, the POPOSigningKeyInput
       structure would be filled out using the sender choice for
       authInfo.  The public key for the certificate being requested
       would be placed in both the POPOSigningKeyInput and the
       Certificate Template structures.  The signature field is computed
       over the DER-encoded POPOSigningKeyInput structure.



Schaad                      Standards Track                     [Page 7]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   3.  The certificate subject places its name in the Certificate
       Template structure along with the public key.  In this case the
       poposkInput field is omitted from the POPOSigningKey structure.
       The signature field is computed over the DER-encoded certificate
       template structure.

   POPOSigningKey ::= SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }

   The fields of POPOSigningKey have the following meaning:

      poposkInput contains the data to be signed, when present.  This
      field MUST be present when the certificate template does not
      contain both the public key value and a subject name value.

      algorithmIdentifier identifiers the signature algorithm and an
      associated parameters used to produce the POP value.

      signature contains the POP value produce.  If poposkInput is
      present, the signature is computed over the DER-encoded value of
      poposkInput.  If poposkInput is absent, the signature is computed
      over the DER-encoded value of certReq.

   POPOSigningKeyInput ::= SEQUENCE {
       authInfo            CHOICE {
           sender              [0] GeneralName,
           -- used only if an authenticated identity has been
           -- established for the sender (e.g., a DN from a
           -- previously-issued and currently-valid certificate)
           publicKeyMAC        PKMACValue },
           -- used if no authenticated GeneralName currently exists for
           -- the sender; publicKeyMAC contains a password-based MAC
           -- on the DER-encoded value of publicKey
       publicKey           SubjectPublicKeyInfo }  -- from CertTemplate

   The fields of POPOSigningKeyInput have the following meaning:

      sender contains an authenticated identity that has been previously
      established for the subject.

      publicKeyMAC contains a computed value that uses a shared secret
      between the CA/RA and the certificate requestor.

      publicKey contains a copy of the public key from the certificate
      template.  This MUST be exactly the same value as is contained in
      the certificate template.



Schaad                      Standards Track                     [Page 8]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   PKMACValue ::= SEQUENCE {
      algId  AlgorithmIdentifier,
      value  BIT STRING }

   The fields of PKMACValue have the following meaning:

      algId identifies the algorithm used to compute the MAC value.  All
      implementations MUST support id-PasswordBasedMAC.  The details on
      this algorithm are presented in section 4.4.

      value contains the computed MAC value.  The MAC value is computed
      over the DER-encoded public key of the certificate subject.

   The CA/RA identifies the shared secret to be used by looking at 1)
   the general name field in the certificate request or 2) either the
   regToken (see section 6.1) or authToken (see section 6.2) controls.

4.2.  Key Encipherment Keys

   POP for key encipherment keys is accomplished by one of three
   different methods.  The private key can be provided to the CA/RA, an
   encrypted challenge from the CA/RA can be decrypted (direct method),
   or the created certificate can be returned encrypted and used as the
   challenge response (indirect method).

   POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,   -- deprecated
       subsequentMessage [1] SubsequentMessage,
       dhMAC             [2] BIT STRING,   -- deprecated
       agreeMAC          [3] PKMACValue,
       encryptedKey      [4] EnvelopedData }
     -- for keyAgreement (only), possession is proven in this message
     -- (which contains a MAC (over the DER-encoded value of the
     -- certReq parameter in CertReqMsg, which must include both subject
     -- and publicKey) based on a key derived from the end entity's
     -- private DH key and the CA's public DH key);
     -- the dhMAC value MUST be calculated as per the directions given
     -- in RFC 2875 for static DH proof-of-possession.

   SubsequentMessage ::= INTEGER {
       encrCert (0),
       challengeResp (1) }

   The fields of POPOPrivKey have the following meaning:

      thisMessage contains the encrypted private key for which a
      certificate is to be issued.  The possession of the private key is
      proved by providing it to the CA/RA.  This field was incorrectly



Schaad                      Standards Track                     [Page 9]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


      typed when the specification was first written.  The correct way
      to use this field is to create an EncryptedValue structure where
      the encrypted content is the private key, the EncryptedValue
      structure is then wrapped in the BIT STRING type.  This field has
      been deprecated in favor of encryptedKey.

      subsequentMessage is used to indicate that the POP will be
      completed by decrypting a message from the CA/RA and returning a
      response.  The type of message to be decrypted is indicated by the
      value used.

         encrCert indicates that the certificate issued is to be
         returned in an encrypted form.  The requestor is required to
         decrypt the certificate and prove success to the CA/RA.  The
         details of this are provided by the CRP.

         challengeResponse indicates that a challenge message is to be
         sent from the CA/RA to the requestor.  The details of the
         challenge message and the response are to be provided by the
         CRP.

      dhMAC is used for Diffie-Hellman key agreement keys.  It contains
      a computed MAC that is obtained by using the requestor's private
      key and the CA/RA public key.  The use of this field is deprecated
      in favor of the agreeMAC field.  Details are covered in section
      4.3.

      agreeMAC is used for key agreement keys.  It contains a computed
      MAC that is obtained by using the requestor's private key and a
      matching CA/RA public key.  Details are covered in section 4.3.

         macAlg contains the algorithm identifying the method used to
         compute the MAC value.

         macValue contains the computed MAC value.

      encryptedKey contains the encrypted private key matching the
      public key for which the certificate is to be issued.  It also
      contains an identification value to indicate it was constructed by
      the requestor of the certificate.  The enveloped content type MUST
      be id-ct-encKeyWithID.

   It is expected that protocols that incorporate this specification
   will include the confirmation and challenge-response messages
   necessary for a complete protocol.






Schaad                      Standards Track                    [Page 10]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


4.2.1.  Private Key Info Content Type

   This content type is used for 1) proving possession of private keys
   and 2) escrow of private keys (using the archive options control in
   section 6.4).  This structure is based on the private key info
   structure from [PKCS8] but has one deliberate difference.  There is a
   potential attack on escrow agents if they decrypt the private key but
   don't know to whom the encrypted key is supposed to belong.  An
   attacker could intercept the encrypted private key, build a
   certificate request around it and then ask for a recovery operation
   on the private key.

   This content type and its structure are:

      id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}

      EncKeyWithID ::= SEQUENCE {
        privateKey           PrivateKeyInfo,
        identifier CHOICE {
          string               UTF8String,
          generalName          GeneralName
        } OPTIONAL
      }

      PrivateKeyInfo ::= SEQUENCE {
         version                   INTEGER,
         privateKeyAlgorithm       AlgorithmIdentifier,
         privateKey                OCTET STRING,
         attributes                [0] IMPLICIT Attributes OPTIONAL
      }

   Attributes ::= SET OF Attribute

   The fields of EncKeyWithID are defined as:

      privateKey contains the encoded private key.  Definitions for
      three private key formats are included in this document.
      Specifications for asymmetric algorithms need to include both the
      public and private key definitions for consistency.

      identifier contains a name that the CA/RA can associate with the
      requestor.  This will generally be either the DN of a certificate
      or a text token passed and known to both the requestor and the
      CA/RA.  This field MUST be present if the purpose is to prove
      possession of the private key.  The field SHOULD be present if
      archiving a key and the archive agent is expected to decrypt the
      key.




Schaad                      Standards Track                    [Page 11]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   The fields of PrivatekeyInfo are define as:

      version MUST be the value 0

      privateKeyAlgorithm contains the identifier for the private key
      object

      privateKey is an octet string whose contents is the private key
      and whose format is defined by the value of privateKeyAlgorithm.

      attributes is a set of attributes.  They are extended information
      that is part of the private key information.

4.2.2.  Private Key Structures

   We are defining the structures here to be used for three algorithms.

4.2.2.1.  D-H Private Keys

   When creating a PrivateKeyInfo for a D-H key, the following rules
   apply:

     1. The privateKeyAlgorithm MUST be set to id-dh-private-number.
        The parameter for id-dh-private-number is DomainParameters
        (imported from [PKIXALG]).

     2. The ASN structure for privateKey MUST be

        DH-PrivateKey ::= INTEGER

     3. The attributes field MUST be omitted.

4.2.2.2.  DSA Private Keys

   When creating a PrivateKeyInfo for a DSA key, the following rules
   apply:

     1. The privateKeyAlgorithm MUST be set to id-dsa.  The parameters
        for id-dsa is Dss-Parms (imported from [PKIXALG]).

     2. The ASN structure for privateKey MUST be

        DSA-PrivateKey ::= INTEGER

     3. The attributes field MUST be omitted.






Schaad                      Standards Track                    [Page 12]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


4.2.2.3.  RSA Private Keys

   When creating a PrivateKeyInfo for an RSA key, the following rules
   apply:

     1. The privateKeyAlgorithm MUST be set to rsaEncryption.

     2. The ASN structure for privateKey MUST be RSAPrivateKey (defined
        in [PKCS1])

     3. The attributes field MUST be omitted.

4.2.3.  Challenge-Response Guidelines

   The following provides guidelines to enrollment protocol authors
   about how an indirect proof-of-possession is expected to work and
   about some of the areas where one needs to be careful in crafting the
   messages to implement this POP method.

   1.  The original enrollment request includes a proof of identity of
       some type and the public portion of the encryption key.  Note
       that the proof of identity needs to cover the public portion of
       the encryption key to prevent substitution attacks (where the
       attacker changes your public key for his public key).

   2.  The response message from the server includes an encrypted data
       value of some type.  That value needs to be authenticated in some
       fashion as having come from the server.  The specification needs
       to include the specifics of how this value is returned for the
       different key types.  For RSA keys, the value can be specified as
       being directly encrypted by the RSA public key; this will not
       work for a D-H key where you need to specify an indirect
       mechanism to encrypt the value.

   3.  The second request message includes a hash of the decrypted
       value.  This message MUST NOT be just the hash of the encrypted
       value, as one should never "sign" a completely random value.  It
       is desirable to include information such as the identity string
       in the hashing process so that this can be made explicitly.  This
       returned value MUST be included in a second proof of identity.

   It is strongly suggested that transaction identifiers and nonce
   values be required when performing indirect POP, as this allows for
   1) tying the different messages in the process together and 2)
   letting each entity inject some amount of random data into the
   process of doing identity proofs.





Schaad                      Standards Track                    [Page 13]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


4.3.  Key Agreement Keys

   POP for key agreement keys is accomplished by one of four different
   methods.  The first three are identical to those presented above for
   key encryption keys.  The fourth method takes advantage of the fact
   that a shared secret is produced and that the value can be used to
   MAC information.

   When the direct or indirect encryption methods presented above are
   used, the CA/RA will need to create an ephemeral key for those cases
   where the encryption algorithm parameters do not match between the
   CA/RA and the requestor.

   The end entity may also MAC the certificate request (using a shared
   secret key derived from computation) as a fourth alternative for
   demonstrating POP.  This option may be used only if the CA/RA already
   has a certificate that is known to the end entity and if the Subject
   is able to use the CA/RA's parameters.

   For the DH key agreement algorithm, all implementations MUST support
   the static DH Proof-of-Possession.  Details on this algorithm can be
   found in section 3 of [RFC2875].  NOTE: If either the subject or
   issuer name in the CA certificate is empty, then the alternative name
   should be used in its place.

4.4.  Use of Password-Based MAC

   This MAC algorithm was designed to take a shared secret (a password)
   and use it to compute a check value over a piece of information.  The
   assumption is that, without the password, the correct check value
   cannot be computed.  The algorithm computes the one-way function
   multiple times in order to slow down any dictionary attacks against
   the password value.

   The algorithm identifier and parameter structure used for Password-
   Based MAC is:

      id-PasswordBasedMAC OBJECT IDENTIFIER ::=
                                         { 1 2 840 113533 7 66 13}

      PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         iterationCount      INTEGER,
         mac                 AlgorithmIdentifier
         )





Schaad                      Standards Track                    [Page 14]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   The fields of PEMParameter have the following meaning:

      salt contains a randomly generated value used in computing the key
      of the MAC process.  The salt SHOULD be at least 8 octets (64
      bits) long.

      owf identifies the algorithm and associated parameters used to
      compute the key used in the MAC process.  All implementations MUST
      support SHA-1.

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      minimum of 100.  Many people suggest using values as high as 1000
      iterations as the minimum value.  The trade off here is between
      protection of the password from attacks and the time spent by the
      server processing all of the different iterations in deriving
      passwords.  Hashing is generally considered a cheap operation but
      this may not be true with all hash functions in the future.

      mac identifies the algorithm and associated parameters of the MAC
      function to be used.  All implementations MUST support HMAC-SHA1
      [HMAC].  All implementations SHOULD support DES-MAC and Triple-
      DES-MAC [PKCS11].

   The following is pseudo-code for the algorithm:

   Inputs:
          pw   - an octet string containing the user's password
          data - an octet string containing the value to be MAC-ed
          Iter - iteration count

   Output:
          MAC  - an octet string containing the resultant MAC value

   1.  Generate a random salt value S

   2.  Append the salt to the pw.  K = pw || salt.

   3.  Hash the value of K.  K = HASH(K)

   4.  If Iter is greater than zero.  Iter = Iter - 1.  Goto step 3.

   5.  Compute an HMAC as documented in [HMAC].

       MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )

       Where opad and ipad are defined in [HMAC].




Schaad                      Standards Track                    [Page 15]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


5.  CertRequest syntax

   The CertRequest syntax consists of a request identifier, a template
   of certificate content, and an optional sequence of control
   information.

   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

   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 } --at least one must be present

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

   The fields of CertRequest have the following meaning:

      certReqId contains an integer value that is used by the
      certificate requestor to associate a specific certificate request
      with a certificate response.

      certTemplate contains a template of an X.509 certificate.  The
      requestor fills in those fields for which specific values are
      desired.  Details on the fields are given below.

      controls contains attributes that are not part of the certificate,
      but control the context in which the certificate is to be issued.
      Details on the controls defined in this document can be found in
      section 6.  Other documents may define other controls.  CRPs are
      responsible for specifying which controls are required.





Schaad                      Standards Track                    [Page 16]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   The fields of CertTemplate have the following meaning:

      version MUST be 2 if supplied.  It SHOULD be omitted.

      serialNumber MUST be omitted.  This field is assigned by the CA
      during certificate creation.

      signingAlg MUST be omitted.  This field is assigned by the CA
      during certificate creation.

      issuer is normally omitted.  It would be filled in with the CA
      that the requestor desires to issue the certificate in situations
      where an RA is servicing more than one CA.

      validity is normally omitted.  It can be used to request that
      certificates either start at some point in the future or expire at
      some specific time.  A case where this field would commonly be
      used is when a cross certificate is issued for a CA.  In this case
      the validity of an existing certificate would be placed in this
      field so that the new certificate would have the same validity
      period as the existing certificate.  If validity is not omitted,
      then at least one of the sub-fields MUST be specified.  The sub-
      fields are as follows:

         notBefore contains the requested start time of the certificate.
         The time follows the same rules as the notBefore time in
         [PROFILE].

         notAfter contains the requested expiration time of the
         certificate.  The time follows the same rules as the notAfter
         time in [PROFILE].

      subject is filled in with the suggested name for the requestor.
      This would normally be filled in by a name that has been
      previously issued to the requestor by the CA.

      publicKey contains the public key for which the certificate is
      being created.  This field MUST be filled in if the requestor
      generates its own key.  The field is omitted if the key is
      generated by the RA/CA.

      issuerUID MUST be omitted.  This field has been deprecated in
      [PROFILE].

      subjectUID MUST be omitted.  This field has been deprecated in
      [PROFILE].





Schaad                      Standards Track                    [Page 17]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


      extensions contains extensions that the requestor wants to have
      placed in the certificate.  These extensions would generally deal
      with things such as setting the key usage to keyEncipherment.

   With the exception of the publicKey field, the CA/RA is permitted to
   alter any requested field.  The returned certificate needs to be
   checked by the requestor to see if the fields have been set in an
   acceptable manner.  CA/RA SHOULD use the template fields if possible.

   There are cases where all fields of the template can be omitted.  If
   the key generation is being done at the CA/RA and the identity proof
   is placed in a different location (such as the id-regCtrl-regToken
   below), then there are no fields that need to be specified by the
   certificate requestor.

6.  Controls Syntax

   The generator of a CertRequest may include one or more control values
   pertaining to the processing of the request.

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

   The following controls are defined by this document:  regToken
   (section 6.1); authenticator (section 6.2); pkiPublicationInfo
   (section 6.3); pkiArchiveOptions (section 6.4); oldCertID (section
   6.5); protocolEncrKey (section 6.6).  Each CRP MUST define the set of
   controls supported by that protocol.  Additional controls may be
   defined by additional RFCs or by the CRP protocol itself.

6.1.  Registration Token Control

   A regToken control contains one-time information (either based on a
   secret value or other shared information) intended to be used by the
   CA to verify the identity of the subject prior to issuing a
   certificate.  Upon receipt of a certification request containing a
   value for regToken, the receiving CA verifies the information in
   order to confirm the identity claimed in the certification request.

   The value for regToken may be generated by the CA and provided out of
   band to the subscriber, or may otherwise be available to both the CA
   and the subscriber.  The security of any out-of-band exchange should
   be commensurate with the risk that the CA will tolerate with regard
   to accepting an intercepted value from someone other than the
   intended subscriber.  The regToken value is not encrypted on return,
   if the data is considered to be sensitive, it needs to be shrouded by
   the requestor.





Schaad                      Standards Track                    [Page 18]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   The regToken control is used only for initialization of an end entity
   into the PKI, whereas the authenticator control (see section 7.2) can
   be used for the initial as well as subsequent certification requests.

   In some instances of use the value for regToken could be a text
   string or a numeric quantity such as a random number.  In the latter
   case, the value is encoded as a text string representation of the
   binary quantity.  The encoding of regToken SHALL be UTF8String.

   id-regCtrl-regToken            OBJECT IDENTIFIER ::= { id-regCtrl 1 }

   Without prior agreement between the subscriber and CA agents, this
   value would be a textual shared secret of some type.  If a computed
   value based on that shared secret is to be used instead, it is
   suggested that the CRP define a new registration control for that
   specific computation.

6.2.  Authenticator Control

   An authenticator control contains information used on an ongoing
   basis to establish a non-cryptographic check of identity in
   communication with the CA.  Examples include:  mother's maiden name,
   last four digits of social security number, or other knowledge-based
   information shared with the subscriber's CA; a hash of such
   information; or other information produced for this purpose.  The
   value for an authenticator control may be generated by the subscriber
   or by the CA.

   In some instances of use, the value for authenticator could be a text
   string or a numeric quantity such as a random number.  The value in
   the latter case is encoded as a text string representation of the
   binary quantity.  The encoding of authenticator SHALL be UTF8String.

   id-regCtrl-authenticator       OBJECT IDENTIFIER ::= { id-regCtrl 2 }

   When deciding whether to use an authenticator or a regToken, use the
   following guidelines.  If the value is a one-time usage value, then
   regToken would be used.  If the value has a long-term usage, then the
   authenticator control would be used.

6.3.  Publication Information Control

   The pkiPublicationInfo control enables subscribers to influence the
   CA/RA's publication of the certificate.  This control is considered
   advisory and can be ignored by CAs/RAs.  It is defined by the
   following OID and syntax:





Schaad                      Standards Track                    [Page 19]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   id-regCtrl-pkiPublicationInfo  OBJECT IDENTIFIER ::= { id-regCtrl 3 }

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

   SinglePubInfo ::= SEQUENCE {
         pubMethod    INTEGER {
             dontCare    (0),
             x500        (1),
             web         (2),
             ldap        (3) },
         pubLocation  GeneralName OPTIONAL }

   The fields of PKIPublicationInfo have the following meaning:

      action indicates whether or not the requestor wishes the CA/RA to
      publish the certificate.  The values and their means are:

         dontPublish indicates that the requester wishes the CA/RA not
         to publish the certificate (this may indicate that the
         requester intends to publish the certificate him/herself).  If
         dontPublish is used, the pubInfos field MUST be omitted.

         pleasePublish indicates that the requestor wishes the CA/RA to
         publish the certificate.

      pubInfos holds the locations where the requestor desires the CA/RA
      to publish the certificate.  This field is omitted if the
      dontPublish choice is selected.  If the requestor wants to specify
      some locations for the certificate to be published, and to allow
      the CA/RA to publish in other locations, it would specify multiple
      values of the SinglePubInfo structure, one of which would be
      dontCare.

   The fields of SinglePubInfo have the following meaning:

      pubMethod indicates the address type for the location at which the
      requestor desires the certificate to be placed by the CA/RA.

         dontCare indicates that the CA/RA can publish the certificate
         in whatever locations it chooses.  If dontCare is used, the
         pubInfos field MUST be omitted.






Schaad                      Standards Track                    [Page 20]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


         x500 indicates that the requestor wishes for the CA/RA to
         publish the certificate in a specific location.  The location
         is indicated in the x500 field of pubLocation.

         ldap indicates that the requestor wishes for the CA/RA to
         publish the certificate in a specific location.  The location
         is indicated in the ldap field of pubLocation.

         web indicates that the requestor wishes for the CA/RA to
         publish the certificate in a specific location.  The location
         is indicated in the http field of pubLocation.

      pubLocation contains the address at which the certificate is to be
      placed.  The choice in the general name field is dictated by the
      pubMethod selection in this structure.

   Publication locations can be supplied in any order.  All locations
   are to be processed by the CA for purposes of publication.

6.4.  Archive Options Control

   The pkiArchiveOptions control enables subscribers to supply
   information needed to establish an archive of the private key
   corresponding to the public key of the certification request.  It is
   defined by the following OID and syntax:

   id-regCtrl-pkiArchiveOptions   OBJECT IDENTIFIER ::= { id-regCtrl 4 }

   PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedKey,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key to be re-generated
      archiveRemGenPrivKey [2] BOOLEAN }
      -- set to TRUE if sender wishes receiver to archive the private
      -- key of a key pair that the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.

   EncryptedKey ::= CHOICE {
      encryptedValue        EncryptedValue, -- deprecated
      envelopedData     [0] EnvelopedData }
      -- The encrypted private key MUST be placed in the envelopedData
      -- encryptedContentInfo encryptedContent OCTET STRING.

   EncryptedValue ::= SEQUENCE {
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
      -- the intended algorithm for which the value will be used
      symmAlg       [1] AlgorithmIdentifier  OPTIONAL,



Schaad                      Standards Track                    [Page 21]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


      -- the symmetric algorithm used to encrypt the value
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- the (encrypted) symmetric key used to encrypt the value
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
      -- algorithm used to encrypt the symmetric key
      valueHint     [4] OCTET STRING         OPTIONAL,
      -- a brief description or identifier of the encValue content
      -- (may be meaningful only to the sending entity, and used only
      -- if EncryptedValue might be re-examined by the sending entity
      -- in the future)
      encValue       BIT STRING }
   -- The use of the EncryptedValue field has been deprecated in favor
   -- of the EnvelopedData structure.
   --
   -- When EncryptedValue is used to carry a private key (as opposed to
   -- a certificate), implementations MUST support the encValue field
   -- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
   -- section 12.11.  If encValue contains some other format/encoding
   -- for the private key, the first octet of valueHint MAY be used
   -- to indicate the format/encoding (but note that the possible values
   -- of this octet are not specified at this time).  In all cases, the
   -- intendedAlg field MUST be used to indicate at least the OID of
   -- the intended algorithm of the private key, unless this information
   -- is known a priori to both sender and receiver by some other means.

   KeyGenParameters ::= OCTET STRING

   The fields of PKIArchiveOptions have the following meaning:

      encryptedPrivKey contains an encrypted version of the private key.

      keyGenParameters contains the information needed by the requestor
      to regenerate the private key.  As an example, for many RSA
      implementations one could send the first random number(s) tested
      for primality.  The structure to go here is not defined by this
      document.  CRPs that define content for this structure MUST define
      not only the content that is to go here, but also how that data is
      shrouded from unauthorized access.

      archiveRemGenPrivKey indicates that the requestor desires that the
      key generated by the CA/RA on the requestor's behalf be archived.

   The fields of EncryptedKey have the following meaning:

      encryptedValue is longer used.  This field has been deprecated
      along with the EncryptedValue structure.





Schaad                      Standards Track                    [Page 22]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


      envelopedData contains the encrypted value of the private key.
      CPRs that use this structure MUST define the entity or entities
      for whom the data is to be encrypted (the EE, escrow agents, CAs)
      and how that key or set of keys is to be determined.  Details on
      constructing an EnvelopedData structure are found in [CMS].  The
      encrypted content MUST be an id-ct-encKeyWithID.  The identifier
      can be omitted unless this structure is also being used to do
      proof-of-possession.

6.5.  OldCert ID Control

   If present, the OldCertID control specifies the certificate to be
   updated by the current certification request.  The OID and syntax is:

   id-regCtrl-oldCertID           OBJECT IDENTIFIER ::= { id-regCtrl 5 }

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

6.6.  Protocol Encryption Key Control

   If present, the protocolEncrKey control specifies a key that the CA
   is to use in encrypting a response to CertReqMessages.  The OID for
   this control is id-regCtrl-protocolEncrKey.  The parameter structure
   for this field is SubjectPublicKeyInfo.  (This structure is defined
   in [PROFILE].)

   id-regCtrl-protocolEncrKey     OBJECT IDENTIFIER ::= { id-regCtrl 6 }

   This control is used when a CA has information to send to the
   subscriber that needs to be encrypted.  Such information includes a
   private key generated by the CA for use by the subscriber.

7.  RegInfo Controls

   This section documents the controls that are to be placed in the
   regInfo field of the CertReqMsg structure.

7.1.  utf8Pairs

   This control is used to convey text-based information from the
   Subject to an RA to a CA issuing a certificate.  The OID for this
   structure is id-regInfo-utf8Paris and has a type of UTF8String.

      id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }




Schaad                      Standards Track                    [Page 23]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   The name is terminated by the question mark character ('?').  The
   value is terminated by the percent character '%'.  Name value pairs
   can be repeated.  Thus the syntax is:

      Name?Value%[Name?Value%]*

   The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%'
   (%25) if they are not being used for their reserved purpose.  Names
   MUST NOT start with a numeric character.

   This control can appear multiple times in the regInfo structure.
   Resolution of conflicts of information is a matter of local policy on
   the RA/CA.

   Appendix A contains a set of common names and data formats
   corresponding to fields that commonly appear in certificates and
   directories.

7.2.  certReq

   This control is designed to deal with the problem where an RA needs
   to modify the certificate template proposed by a Subject, but the
   Subject used the certificate template as part of its POP calculation.
   In this case, the RA can place a new certificate template in the
   regInfo sequence.

   This control has the OID id-regInfo-certReq and the structure
   CertRequest.  There can only be one instance of this attribute in the
   regInfo sequence.  If this control exists in the regInfo structure,
   then the certificate template in the request is ignored.  The RA MUST
   copy all data from the core template to this attribute.

      id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }

8.  Object Identifiers

   The OID id-pkix has the value

   id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
   dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

   -- arc for Internet X.509 PKI protocols and their components
   id-pkip  OBJECT IDENTIFIER :: { id-pkix pkip(5) }

   -- arc for Registration Controls in CRMF
   id-regCtrl  OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }





Schaad                      Standards Track                    [Page 24]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   -- arc for Registration Info in CRMF
   id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }

9.  Security Considerations

   Enrollment protocols, by their very nature, involve large amounts of
   private information.  This can include private keys, identity
   numbers, credit card numbers, and the like.  The security of any CRP
   is based on the security mechanisms of the protocol and/or process
   used to communicate between CAs, RAs and EEs.  All protocols must
   provide for masking, either via encryption or off-line processing, of
   all subscriber-sensitive information.

   Many enrollment protocols provide for the initial establishment of
   identity between the CA/RA and the EE by the use of a token.
   Generally this token is delivered using an out-of-band delivery
   method (such as the governmental mail system).  The security of any
   out-of-band exchange needs to be commensurate with the risk that the
   CA/RA will tolerate with regard to interception of the token by a
   third party.

   Implementation must implement Proof-of-Possession (POP) values during
   certificate enrollment processes.  A good POP algorithm needs to
   provide proof of two things: 1) that the key is tied to a specific
   user and 2) that the user has use of the key in question.  Failure to
   implement POP allows people to create certificates where the public
   key and the name values do not correctly bind.  This allows for
   impersonation on signature keys and interception of encrypted
   messages.

   Implementations must use high entropy random number generators in
   producing private keys.  Implementations must randomly generate
   content-encryption keys, message-authentication keys, initialization
   vectors (IVs), salt, and padding.  The use of inadequate pseudo-
   random number generators (PRNGs) to generate cryptographic keys can
   result in little or no security.  An attacker may find it much easier
   to reproduce the PRNG environment that produced the keys, searching
   the resulting small set of possibilities, rather than brute force
   searching the whole key space.  The generation of quality random
   numbers is difficult.  RFC 4086 [RANDOM] offers important guidance in
   this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
   PRNG technique.

   Implementations must protect private keys.  The compromise of a
   signer's private key permits third parties to masquerade as the
   signer.  The compromise of a decryption private key allows for
   interception of messages by a third party.




Schaad                      Standards Track                    [Page 25]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   One feature of the certificate message request syntax is for the key
   generation to be performed remotely from the creation of the
   certificate request.  This feature should never be used for
   generation of signing keys.  If signing keys are generated for the
   user, then an element of repudiation comes into play.  The user can
   claim that an item was signed by the entity that generated the key as
   well as any entity that might have seen the key value during transfer
   from the generator the to EE.  Care must be taken to protect
   encryption keys by the remote key generator to protect against
   interception of the keys by a third party.  This means that the
   encryption algorithms used need to be secure, and a content
   encryption key or a key encryption key must be used to mask the
   private key during transport back to the user.  CRP protocols must
   never assume that a signature key generated by the user can be used
   to decrypt the package in which an encryption private key is
   transported.

   This document describes a method by which key escrow may be done.
   There are several issues that need to be taken into account when
   doing key escrow.  First, the client must be able to correctly
   identify the entity to which a key is to be escrowed or the CRP must
   provide a method by which the client can discover this information.
   A CRP cannot assume that the key escrow agent and the CA are the same
   entity and thus have the same names.  Second, the algorithms used to
   mask the private key or other key generation information during
   transport to the escrow agent need to be commensurate with the value
   of the data being protected by the key.  Third, the escrow agent
   needs to provide sufficient safeguards that an escrowed key is
   returned only to entities that should be able to obtain the private
   key.  Generally, this should be restricted to the entity that
   escrowed the data.  Fourth, the escrow data base needs to be stored
   in a secure manner.  One common method for doing this is to re-
   encrypt the data to keys that only the escrow agent has access to.
   In this case, one may need to escrow the escrow agent key as well.
   Access to either the escrow agent or the archived key would amount to
   access to all private keys that have been escrowed with that agent.

10.  References

10.1.  Normative References

   [PKCS1]   Jonsson, J. and B. Kaliski, "Public-Key Cryptography
             Standards (PKCS) #1: RSA Cryptography Specifications
             Version 2.1", RFC 3447, February 2003.

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



Schaad                      Standards Track                    [Page 26]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   [PKCS11]  RSA Laboratories, The Public-Key Cryptography Standards -
             "PKCS #11 v2.11:  Cryptographic Token Interface Standard",
             RSA Security Inc., June 2001.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
             X.509 Public Key Infrastructure Certificate and Certificate
             Revocation List (CRL) Profile", RFC 3280, April 2002.

   [PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
             Identifiers for the Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation List
             (CRL) Profile", RFC 3279, April 2002.

   [CMS]     Housley, R., "Cryptographic Message Syntax (CMS)", RFC
             3852, July 2004.

   [RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
             Proof-of-Possession Algorithms", RFC 2875, July 2000.

10.2.  Informative References

   [DSS]     National Institute of Standards and Technology, FIPS Pub
             186: Digital Signature Standard, May 1994.

   [PKCS8]   RSA Laboratories, "PKCS #8: Private-Key Information Syntax
             Standard", PKCS #8 v1.2, November 1993.

   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
             "Randomness Requirements for Security", BCP 106, RFC 4086,
             June 2005.

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

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












Schaad                      Standards Track                    [Page 27]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


11.  Acknowledgements

   The working group would like to thank Michael Myers, Carlisle Adams,
   Dave Solo, and David Kemp, who authored the original version of this
   document.

   The working group also gratefully acknowledges the contributions of
   Barbara Fox, Warwick Ford, Russ Housley, and John Pawling, whose
   review and comments significantly clarified and improved the utility
   of this specification.  The members of the ca-talk mailing list also
   provided significant input with respect to interoperability testing.

   The text of Appendix C (Why do POP) was taken from an e-mail message
   by Al Arsenault and was originally part of the PKIX Roadmap document.





































Schaad                      Standards Track                    [Page 28]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


Appendix A.  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 UTF-8 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.

A.1.  Defined Names

   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?Example, Inc.%org_unit?Engineering%
      mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
      mail_email?john@example.com%

A.2.  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.



Schaad                      Standards Track                    [Page 29]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


      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 more UTF-8 characters.  Within a name
   value, when it is necessary to disambiguate a character that 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>













Schaad                      Standards Track                    [Page 30]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


   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 UTF-8 character string
   of 1 to 64 characters, with the restriction that in the IA5 subset of
   UTF-8 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=Example,C=US% subjectName?XCN=John Smith,
      O=Example, C=US, E=john@example.com%
















Schaad                      Standards Track                    [Page 31]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


Appendix B.  ASN.1 Structures and OIDs

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

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

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

  -- 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(19)}  -- found in [PROFILE]

  -- Cryptographic Message Syntax
     EnvelopedData
        FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             modules(0) cms-2004(24) };  -- found in [CMS]

-- The following definition may be uncommented for use with
-- ASN.1 compilers that do not understand UTF8String.

-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
       -- The contents of this type correspond to RFC 2279.

id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }

-- arc for Internet X.509 PKI protocols and their components

id-pkip  OBJECT IDENTIFIER ::= { id-pkix 5 }

id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

id-ct   OBJECT IDENTIFIER ::= { id-smime  1 }  -- content types






Schaad                      Standards Track                    [Page 32]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


-- Core definitions for this module

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

CertReqMsg ::= SEQUENCE {
 certReq   CertRequest,
 popo       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

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 } -- at least one MUST be present

Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
 type         OBJECT IDENTIFIER,
 value        ANY DEFINED BY type }

ProofOfPossession ::= CHOICE {
 raVerified        [0] NULL,
 -- used if the RA has already verified that the requester is in
 -- possession of the private key
 signature         [1] POPOSigningKey,
 keyEncipherment   [2] POPOPrivKey,
 keyAgreement      [3] POPOPrivKey }

POPOSigningKey ::= SEQUENCE {
 poposkInput           [0] POPOSigningKeyInput OPTIONAL,
 algorithmIdentifier   AlgorithmIdentifier,
 signature             BIT STRING }



Schaad                      Standards Track                    [Page 33]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


 -- The signature (using "algorithmIdentifier") is on the
 -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
 -- certReq CertTemplate contains the subject and publicKey values,
 -- then poposkInput MUST be omitted and the signature MUST be
 -- computed over the DER-encoded value of CertReqMsg certReq.  If
 -- the CertReqMsg certReq CertTemplate does not contain both the
 -- public key and subject values (i.e., if it contains only one
 -- of these, or neither), then poposkInput MUST be present and
 -- MUST be signed.


POPOSigningKeyInput ::= SEQUENCE {
 authInfo            CHOICE {
     sender              [0] GeneralName,
     -- used only if an authenticated identity has been
     -- established for the sender (e.g., a DN from a
     -- previously-issued and currently-valid certificate)
     publicKeyMAC        PKMACValue },
     -- used if no authenticated GeneralName currently exists for
     -- the sender; publicKeyMAC contains a password-based MAC
     -- on the DER-encoded value of publicKey
 publicKey           SubjectPublicKeyInfo }  -- from CertTemplate

PKMACValue ::= SEQUENCE {
algId  AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value  BIT STRING }

PBMParameter ::= SEQUENCE {
   salt                OCTET STRING,
   owf                 AlgorithmIdentifier,
   -- AlgId for a One-Way Function (SHA-1 recommended)
   iterationCount      INTEGER,
   -- number of times the OWF is applied
   mac                 AlgorithmIdentifier
   -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
}   -- or HMAC [HMAC, RFC2202])

POPOPrivKey ::= CHOICE {
 thisMessage       [0] BIT STRING,         -- Deprecated
 -- possession is proven in this message (which contains the private
 -- key itself (encrypted for the CA))
 subsequentMessage [1] SubsequentMessage,
 -- possession will be proven in a subsequent message
 dhMAC             [2] BIT STRING,         -- Deprecated
 agreeMAC          [3] PKMACValue,
 encryptedKey      [4] EnvelopedData }



Schaad                      Standards Track                    [Page 34]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


 -- for keyAgreement (only), possession is proven in this message
 -- (which contains a MAC (over the DER-encoded value of the
 -- certReq parameter in CertReqMsg, which MUST include both subject
 -- and publicKey) based on a key derived from the end entity's
 -- private DH key and the CA's public DH key);

SubsequentMessage ::= INTEGER {
 encrCert (0),
 -- requests that resulting certificate be encrypted for the
 -- end entity (following which, POP will be proven in a
 -- confirmation message)
 challengeResp (1) }
 -- requests that CA engage in challenge-response exchange with
 -- end entity in order to prove private key possession

-- Object identifier assignments --

-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }


id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String

id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String

id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:

PKIPublicationInfo ::= SEQUENCE {
action     INTEGER {
             dontPublish (0),
             pleasePublish (1) },
pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
  -- pubInfos MUST NOT be present if action is "dontPublish"
  -- (if action is "pleasePublish" and pubInfos is omitted,
  -- "dontCare" is assumed)

SinglePubInfo ::= SEQUENCE {
 pubMethod    INTEGER {
     dontCare    (0),
     x500        (1),
     web         (2),
     ldap        (3) },
 pubLocation  GeneralName OPTIONAL }



Schaad                      Standards Track                    [Page 35]
^L
RFC 4211                  Internet X.509 CRMF             September 2005



id-regCtrl-pkiArchiveOptions     OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
 encryptedPrivKey     [0] EncryptedKey,
 -- the actual value of the private key
 keyGenParameters     [1] KeyGenParameters,
 -- parameters that allow the private key to be re-generated
 archiveRemGenPrivKey [2] BOOLEAN }
 -- set to TRUE if sender wishes receiver to archive the private
 -- key of a key pair that the receiver generates in response to
 -- this request; set to FALSE if no archival is desired.

EncryptedKey ::= CHOICE {
 encryptedValue        EncryptedValue,   -- Deprecated
 envelopedData     [0] EnvelopedData }
 -- The encrypted private key MUST be placed in the envelopedData
 -- encryptedContentInfo encryptedContent OCTET STRING.

EncryptedValue ::= SEQUENCE {
 intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
 -- the intended algorithm for which the value will be used
 symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
 -- the symmetric algorithm used to encrypt the value
 encSymmKey    [2] BIT STRING           OPTIONAL,
 -- the (encrypted) symmetric key used to encrypt the value
 keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
 -- algorithm used to encrypt the symmetric key
 valueHint     [4] OCTET STRING         OPTIONAL,
 -- a brief description or identifier of the encValue content
 -- (may be meaningful only to the sending entity, and used only
 -- if EncryptedValue might be re-examined by the sending entity
 -- in the future)
 encValue       BIT STRING }
 -- the encrypted value itself
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11.  If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time).  In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.

KeyGenParameters ::= OCTET STRING




Schaad                      Standards Track                    [Page 36]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId

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

id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo

-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }

id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String


id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest

-- id-ct-encKeyWithID is a new content type used for CMS objects.
-- it contains both a private key and an identifier for key escrow
-- agents to check against recovery requestors.

id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}

EncKeyWithID ::= SEQUENCE {
  privateKey           PrivateKeyInfo,
  identifier CHOICE {
    string             UTF8String,
    generalName        GeneralName
  } OPTIONAL
}

PrivateKeyInfo ::= SEQUENCE {
   version                   INTEGER,
   privateKeyAlgorithm       AlgorithmIdentifier,
   privateKey                OCTET STRING,
   attributes                [0] IMPLICIT Attributes OPTIONAL
}

Attributes ::= SET OF Attribute

END



Schaad                      Standards Track                    [Page 37]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


Appendix C.  Why do Proof-of-Possession (POP)

   Proof-of-Possession, or POP, means that the CA is adequately
   convinced that the entity requesting a certificate for the public key
   Y, has access to the corresponding private key X.

   POP is important because it provides an appropriate level of
   assurance of the correct operation of the PKI as a whole.  At its
   lowest level, POP counters the "self-inflicted denial of service";
   that is, an entity voluntarily gets a certificate that cannot be used
   to sign or encrypt/decrypt information.  However, as the following
   two examples demonstrate, POP also counters less direct, but more
   severe, threats:

      POP for signing keys: it is important to provide POP for keys used
      to sign material, in order to provide non-repudiation of
      transactions.  For example, suppose Alice legitimately has private
      key X and its corresponding public key Y.  Alice has a certificate
      from Charlie, a CA, containing Y.  Alice uses X to sign a
      transaction T.  Without POP, Mal could also get a certificate from
      Charlie containing the same public key, Y.  Now, there are two
      possible threats: Mal could claim to have been the real signer of
      T; or Alice can falsely deny signing T, claiming that it was
      instead Mal.  Since no one can reliably prove that Mal did or did
      not ever possess X, neither of these claims can be refuted, and
      thus the service provided by and the confidence in the PKI has
      been defeated.  (Of course, if Mal really did possess X, Alice's
      private key, then no POP mechanism in the world will help, but
      that is a different problem.)

      Note that one level of protection can be gained by having Alice
      (as the true signer of the transaction) include in the signed
      information, her certificate or an identifier of her certificate
      (e.g., a hash of her certificate).  This might make it more
      difficult for Mal to claim authorship; he would have to assert
      that he incorrectly included Alice's certificate, rather than his
      own.  However, it would not stop Alice from falsely repudiating
      her actions.  Since the certificate itself is a public item, Mal
      indeed could have inserted Alice's certificate or identifier into
      the signed transaction, and thus its presence does not indicate
      that Alice was the one who participated in the now-repudiated
      transaction.  The only reliable way to stop this attack is to
      require that Mal prove he possesses X before his certificate is
      issued.







Schaad                      Standards Track                    [Page 38]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


      For signing keys used only for authentication, and not for non-
      repudiation, the threat is lower because users may not care about
      Alice's after-the-fact repudiation, and thus POP becomes less
      important.  However, POP SHOULD still be done wherever feasible in
      this environment, by either off-line or on-line means.

      POP for key management keys:  Similarly, POP for key management
      keys (that is, keys used for either key agreement or key exchange)
      can help to prevent undermining confidence in the PKI.  Suppose
      that Al is a new instructor in the Computer Science Department of
      a local university.  Al has created a draft final exam for the
      Introduction to Networking course he is teaching.  He wants to
      send a copy of the draft final to Dorothy, the Department Head,
      for her review prior to giving the exam.  This exam will of course
      be encrypted, as several students have access to the computer
      system.  However, a quick search of the certificate repository
      (e.g., search the repository for all records with
      subjectPublicKey=Dorothy's-value) turns up the fact that several
      students have certificates containing the same public key
      management key as Dorothy.  At this point, if no POP has been done
      by the CA, Al has no way of knowing whether all of the students
      have simply created these certificates without knowing the
      corresponding private key (and thus it is safe to send the
      encrypted exam to Dorothy), or whether the students have somehow
      acquired Dorothy's private key (and thus it is certainly not safe
      to send the exam).  Thus, the service to be provided by the PKI
      allowing users to communicate with one another, with confidence in
      who they are communicating with, has been totally defeated.  If
      the CA is providing POP, then either no students will have such
      certificates, or Al can know with certainty that the students do
      indeed know Dorothy's private key, and act accordingly.

Author's Address

   Jim Schaad
   Soaring Hawk Consulting
   PO Box 675
   Gold Bar, WA 98251

   EMail: jimsch@exmsft.com











Schaad                      Standards Track                    [Page 39]
^L
RFC 4211                  Internet X.509 CRMF             September 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Schaad                      Standards Track                    [Page 40]
^L