GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4211

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] RFC 4211 Internet X.509 CRMF September 2005

  1. - the symmetric algorithm used to encrypt the value

encSymmKey [2] BIT STRING OPTIONAL,

  1. - the (encrypted) symmetric key used to encrypt the value

keyAlg [3] AlgorithmIdentifier OPTIONAL,

  1. - algorithm used to encrypt the symmetric key

valueHint [4] OCTET STRING OPTIONAL,

  1. - a brief description or identifier of the encValue content
  2. - (may be meaningful only to the sending entity, and used only
  3. - if EncryptedValue might be re-examined by the sending entity
  4. - in the future)

encValue BIT STRING }

  1. - The use of the EncryptedValue field has been deprecated in favor
  2. - of the EnvelopedData structure.
  3. -
  4. - When EncryptedValue is used to carry a private key (as opposed to
  5. - a certificate), implementations MUST support the encValue field
  6. - containing an encrypted PrivateKeyInfo as defined in [PKCS11],
  7. - section 12.11. If encValue contains some other format/encoding
  8. - for the private key, the first octet of valueHint MAY be used
  9. - to indicate the format/encoding (but note that the possible values
  10. - of this octet are not specified at this time). In all cases, the
  11. - intendedAlg field MUST be used to indicate at least the OID of
  12. - the intended algorithm of the private key, unless this information
  13. - 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] 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] 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) }
  1. - arc for Internet X.509 PKI protocols and their components

id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }

  1. - arc for Registration Controls in CRMF

id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }

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

  1. - 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] 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] 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] 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] 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] 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] 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] 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

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

  1. - 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] 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] 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] 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 }

  1. - pubInfos MUST NOT be present if action is "dontPublish"
  2. - (if action is "pleasePublish" and pubInfos is omitted,
  3. - "dontCare" is assumed)

SinglePubInfo ::= SEQUENCE { pubMethod INTEGER {

   dontCare    (0),
   x500        (1),
   web         (2),
   ldap        (3) },

pubLocation GeneralName OPTIONAL }

Schaad Standards Track [Page 35] 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] 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] 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] 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] 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4211.txt · Last modified: 2005/09/28 00:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki