NETWORK WORKING GROUP                                          J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Intended Status: Proposed Standard                             S. Turner
Expires: January 31, 2014                                           IECA
                                                               P. Timmel
                                                National Security Agency
                                                           July 30, 2013

     CMC (Certificate Management over Cryptographic Message Syntax)
                   Extensions: Server Key Generation
              draft-turner-cmc-serverkeygeneration-00.txt


Abstract

   This document defines a set of extensions to the Certificate
   Management over Cryptographic Message Syntax (CMC) protocol that
   addresses the desire to support server-side generation of keys.  This
   service is provided by the definition of additional control
   statements within the CMC architecture.  Additional CMC errors are
   also defined.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."















Schaad, et al.          Expires January 31, 2014                [Page 1]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Flows for Supported Scenarios . . . . . . . . . . . .  5
     2.1.  Shared Secret for Authentication and Key Protection  . . .  7
     2.2  Shared Secret for Authentication and Ephemeral Key for
          Protection  . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.3. Certificate for Authentication and Ephemeral Key for
          Protection  . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.4. Certificate for Authentication and Key Protection . . . . . 12
       2.4.1.  Same Certificate for Authentication and Key
               Protection . . . . . . . . . . . . . . . . . . . . . . 12
       2.4.2.  Different Certificates for Authentication and Key
               Protection . . . . . . . . . . . . . . . . . . . . . . 12
     2.5.  RA Scenarios . . . . . . . . . . . . . . . . . . . . . . . 12
       2.5.1.  RA-Generated Key Scenarios . . . . . . . . . . . . . . 14
       2.5.2.  RA-Involved Scenarios  . . . . . . . . . . . . . . . . 17
   3. Generating PKIData and PKIResponse  . . . . . . . . . . . . . . 18
     3.1.  Client Requests  . . . . . . . . . . . . . . . . . . . . . 19
     3.2.  RA Processing of Client Requests . . . . . . . . . . . . . 19
     3.3.  CA Processing  . . . . . . . . . . . . . . . . . . . . . . 21
     3.4.  RA Processing of CA Responses  . . . . . . . . . . . . . . 23
     3.4.  Client Processing of Responses . . . . . . . . . . . . . . 25
   4. Shrouding Algorithms  . . . . . . . . . . . . . . . . . . . . . 25
     4.1. Shroud With a Public Key  . . . . . . . . . . . . . . . . . 26
     4.2. Shroud With a Shared-Secret Key . . . . . . . . . . . . . . 27
   5. Returned Key Format . . . . . . . . . . . . . . . . . . . . . . 28
   6. Server-Side Key Generation  . . . . . . . . . . . . . . . . . . 29
     6.1. Server-Side Key Generation Request Attribute  . . . . . . . 29
     6.2. Server-side Key Generation Response . . . . . . . . . . . . 31
   7. Additional Error Codes  . . . . . . . . . . . . . . . . . . . . 32



Schaad, et al.          Expires January 31, 2014                [Page 2]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   8.  Proof-of-Possession  . . . . . . . . . . . . . . . . . . . . . 33
   9. Security Considerations . . . . . . . . . . . . . . . . . . . . 33
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
   11.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 35
     11.1  Normative References . . . . . . . . . . . . . . . . . . . 35
     12.2  Informative References . . . . . . . . . . . . . . . . . . 36
   Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 37
   Appendix B. Additional Message Flows . . . . . . . . . . . . . . . 37
   Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 41
     B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 41
       B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 41
       B.1.2. Shroud with Public Key  . . . . . . . . . . . . . . . . 41
       B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 41
     B.2. CA-Generate Key Response  . . . . . . . . . . . . . . . . . 41
     B.3. RA-Generate Key Response  . . . . . . . . . . . . . . . . . 41
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41


1  Introduction

   This document defines a set of extensions to and errors for
   Certificate Management over Cryptographic Message Syntax (CMC)
   [RFC5272] that allows for server-side generation of key material.
   There are strong reasons for providing this service:

     o Clients may have poor, unknown, or non-existent key generation
       capabilities.  The creation of private keys relies on the use of
       good key generation algorithms and a robust random number
       generator.  Server key generation can use specialized hardware
       that may not always be available on clients.

     o Central storage of keys may be desired in some environments to
       permit key recovery.  This document only addresses a request to
       archive server-generated keys; archival of locally generated keys
       and the control to retrieve archived keys is out-of-scope.

     o Server key generation may be useful for provisioning keys to
       disconnected clients (e.g., clients that receive keys from a fill
       device [RFC4949] because the clients are not able to connect to
       the server due to an air gap).

   These extensions to the CMC protocol are designed to provide server
   key generation without adding any additional round trips to the
   enrollment process; however, additional round trips may be required
   based on the mechanism chosen to protect the returned key.

   Section 2 describes the enrollment scenarios supported.  Section 3
   provides CMC requirements. Sections 4 and 5 describe the concepts and



Schaad, et al.          Expires January 31, 2014                [Page 3]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   structures used in transporting private keys between the server and
   client applications.  Section 6 describes the structure and processes
   for server-side key generation.  Section 7 describes additional CMC
   error codes.  Section 8 describes additional exchanges when the
   server requires the client provide Proof-of-Possession (POP).
   Appendix A provides the ASN.1 module for the CMC controls and errors.
    Appendix B provides example encodings.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   The terminology in [RFC5272] and in [RFC6402] apply to this profile.
   Additionally, familiarity with CMS's (Cryptographic Message Syntax)
   SignedData, AuthenticatedData, and EnvelopedData content types is
   assumed [rfc5652].

1.2.  Definitions

   This section defines some of the terms that are used in this
   document:

     o Dual-use: Applies to certificates or keys.  Certificates that can
       be used to verify both digital signatures and to perform key
       management, when the Key Usage extension is set to
       digitalSignature and either keyAgreement or keyEncipherment, and
       keys whose intended use is digitalSignature and either
       keyAgreement or keyEncipherment.

     o Encryption-capable: Applies to certificates or keys.
       Certificates that can be used for key management (i.e., the Key
       Usage extension includes keyAgreement or keyEncipherment) and
       keys that can be used for key management.  This refers to either
       dual-use or encryption-only certificates/keys.

     o Encryption-only: Applies to certificates or keys.  Certificates
       that can only be used for key management, when the Key Usage
       extension is set to either keyAgreement or keyEncipherment, and
       keys whose only intended use is keyAgreement or keyEncipherment.

     o Ephemeral key [SP-800-57]: A cryptographic key that is generated
       for each execution of a key establishment process and that meets
       other requirements of the key type (e.g., unique to each message
       or session).  Often, ephemeral keys are linked to key agreement
       algorithms; however, this document uses the term ephemeral keys



Schaad, et al.          Expires January 31, 2014                [Page 4]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


       to apply to both key transport and key agreement keys.  The
       ephemeral key has two parts: the private part and the public
       part.  The client provides the public part to the server to allow
       the server to protect the server-generated keys.  Note that an
       ephemeral key has a security advantage by being unique to the
       session; it SHOULD be freshly generated when possible, but MAY be
       pre-placed when local key generation is of poor or unknown
       quality (see Section 9).  An ephemeral key is innately
       unauthenticated, and so must be carried in a suitably
       authenticated protocol.

     o Identification: A generic term for a process by which a name,
       generally assigned by a server, is used to match a request
       against a known entity.  Identification can be either
       authenticated (a subject name in a certificate) or
       unauthenticated (a text string).

     o Shared Secret: A value known to two or more entities in advance
       of a protocol session in which it will be used, and intended to
       be unknown to any others.  In this document, the value must be a
       suitable basis for derivation of a MAC (Message Authentication
       Code) or encryption key.  Pass phrases that are used as a shared
       secret must be treated as confidential by the holders of the
       secret.

     o Shrouding: A generic term to cover methods of masking the content
       of an object from unauthorized viewers.  The most common method
       of shrouding used is encryption of the data at the application
       layer.  This document defines two shroud methods that employ
       encryption at the application layer but other shrouding methods
       can be defined that don't employ encryption at the application
       layer.

     o Signature-capable: Applies to certificates or keys.  Certificates
       that can be used to verify signatures and keys that can be used
       to generate digital signatures.  This refers to either dual-use
       or signature-only certificates/keys.

     o Signature-only: Applies to certificate or keys.  Certificates
       that can only be used to verify digital signatures, when the Key
       Usage extension is set to digitalSignature, and keys whose only
       intended key usage is digital signature.


2.  Protocol Flows for Supported Scenarios

   This section describes five scenarios, and specifies the CMC requests
   and responses to support them:



Schaad, et al.          Expires January 31, 2014                [Page 5]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


    1. In the first scenario (see Section 2.1), clients use a shared
       secret (e.g., password) (see Section 1.2) to provide
       authentication and request that the server use the same shared
       secret to encrypt the server-generated keys.  Obviously the
       security in this scenario, and any scenario in which a shared
       secret is used, is predicated on keeping the shared secret
       secret.  Here, the client need only know a shared secret to
       request a certificate, but the client needs to maintain secrecy
       of the shared secret, which is often difficult for clients, for
       the lifetime of the key (see Section 9).  Further, using the same
       secret for authentication and encryption potentially increases
       exposure of the server-generated private key among the entities
       comprising the RA and CA.  Note that the use of split-shared
       secret (i.e., one for authentication and one for encryption)
       would alleviate the last concern, but this is beyond the scope of
       this document.

    2. In the second scenario (see Section 2.2), clients use a shared
       secret to provide authentication and request that the server use
       an ephemeral key (see Section 1.2) to encrypt the server-
       generated keys.  Here, the client can still use their shared
       secret to request the certificate but now once encrypted the
       private key can only become known to the client. Also, the key
       that protects the response is ephemeral even if the
       authentication shared secret is not.

    3. In the third scenario (see Section 2.3), clients use a
       certificate to support digital signature authentication and
       request that the server use an ephemeral key to encrypt the
       server-generated keys. Here, the primary motivation is that use
       of the ephemeral key mitigates the risk of compromise of a pre-
       existing certificate and key while in the supply chain (see
       Section 9).

    4. In the fourth scenario (see Section 2.4), clients use a
       certificate to support digital signature authentication and
       request that the server use a certificate to encrypt the server-
       generated keys.  Here, clients can request a certificate with a
       certificate or certificates that the client already has.  There
       are still security requirements for protecting the private key(s)
       associated with the certificate(s) (see Section 9).  If two
       certificates are used (i.e., one for encryption and one for
       digital signatures), the separation between signing and key
       exchange functions is preserved, and supports a broader range of
       algorithms.  Some additional details:

       o If the client's authentication certificate is signature-only,
         then the client also needs an encryption-capable certificate



Schaad, et al.          Expires January 31, 2014                [Page 6]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


         (i.e. having the Key Usage extension set to either keyAgreement
         or keyEncipherment) that the server will use to protect the
         private key.

       o If the client's certificate is dual-use, then the client only
         needs the one certified key pair to generate the SignedData
         that encapsulates the certificate request and to decrypt the
         EnvelopedData that encapsulates the server-generated key.

    5. The first four scenarios assume that the keys are generated at
       the Certification Authority (CA) and that the interactions do not
       involve a Registration Authority (RA) [RFC5280].  But, key
       generation by an RA is also supported as well as scenarios when
       the RA verifies the client's identity (see Section 2.5).

   Note that there is no scenario where the response is protected with a
   key/certificate that only supports digital signatures.  This is
   because the "protection" afforded by digital signatures alone does
   not include confidentiality, which is required to ensure that the
   server-generated private key is only disclosed to the client.

   Note also that there is also no scenario where the client uses an
   encryption-only certificate and is unable to generate a digital
   signature to provide authentication.  This is because the
   "protection" afforded by encryption-only certificates does not
   include authentication.  Technically, there are dual-service
   algorithms that support both authentication and encryption but their
   use is beyond the scope of this document.

   In all of the scenarios, the client can validate that the response
   came from the CA or RA by validating the digital signature on the
   SignedData to a Trust Anchor (TA).  After the EnvelopedData is
   decrypted, the client can 1) verify that the private key is
   associated with the public key in the returned certificate and/or 2)
   verify that the certificate validates back to an authorized TA.

   The scenarios in the subsections assume that the transaction
   identifier and nonce controls are used for transaction processing and
   replay protection, respectively, but they are optional, as specified
   in [RFC5272].  Also, the scenarios assume the CMC Status Information
   v2 control is not included when the response is a success, as allowed
   by [RFC5272].  See Appendix B for additional example scenarios.

2.1.  Shared Secret for Authentication and Key Protection

   The shared secret allows the server to authenticate the client and
   allows the server to encrypt the server-side generated key for the
   client.  The shared secret is distributed via an out-of-band



Schaad, et al.          Expires January 31, 2014                [Page 7]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   mechanism that is out-of-scope of this document.  Also note the
   server and client need to share a non-secret identification string
   that the client can assert in a request so that the server will know
   which shared secret is being used.

   When the client generates their request, the client includes the
   following control attributes in a PKIData content type [RFC5272]:
   Server Key Generation Request (see Section 6.1), Transaction
   Identifier [RFC5272], Sender Nonce [RFC5272], and Identification
   [RFC5272].  The Server Key Generation Request control indicates that
   the shroudMethod is shroud with shared-secret key (see Section 4.2).
   The PKIData is encapsulated in a CMS AuthenticatedData content type
   and the password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652].
    Note that reqSequence, cmsSequence, and otherMsgSequence are not
   included in the PKIData for the server-side key generation request.
   The following depicts this:

     +----------------------------------------------------------------+
     |AuthenticatedData: ReceipientInfo: pwri                         |
     |+--------------------------------------------------------------||
     ||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)||
     ||         control: TransationID                                ||
     ||         control: SenderNonce                                 ||
     ||         control: Identification                              ||
     |+--------------------------------------------------------------+|
     +----------------------------------------------------------------+

   After the server authenticates the client, the server generates a
   response that includes the server-generated key and any associated
   parameters in an Asymmetric Key Package content type [RFC5958].  The
   Asymmetric Key Package is then encapsulated within a SignedData and
   that is further encapsulated within an EnvelopedData using the
   password RecipientInfo (i.e., pwri CHOICE).  The EnvelopedData is
   then placed in a PKIResponse cmsSequence [RFC5272] and the following
   controls are included in the PKIResponse: Transaction Identifier,
   Sender Nonce, Recipient Nonce [RFC5272], and Server Key Generation
   Response (see Section 4.2).  The PKIResponse is then encapsulated in
   a SignedData and the certificate associated with the server-generated
   key is placed in the outer-most SignedData's certificate field
   [RFC5652].  The following depicts this:

     +---------------------------------------------------------+
     |SignedData: Signed by the CA                             |
     |             Client's certificate found here             |
     |+-------------------------------------------------------+|
     ||PKIResponse: control: TransactionID                    ||
     ||             control: SenderNonce                      ||
     ||             control: RecipientNonce                   ||



Schaad, et al.          Expires January 31, 2014                [Page 8]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


     ||             control: ServerKeyGenResponse             ||
     ||                                                       ||
     ||             cmsSequence:                              ||
     ||             +----------------------------------------+||
     ||             |EnvelopedData: RecipientInfo: pwri      |||
     ||             |+----------------------+                |||
     ||             ||SignedData            |                |||
     ||             ||+--------------------+|                |||
     ||             |||AsymmetricKeyPackage||                |||
     ||             ||+--------------------+|                |||
     ||             |+----------------------+                |||
     ||             +----------------------------------------+||
     |+-------------------------------------------------------+|
     +---------------------------------------------------------+

2.2  Shared Secret for Authentication and Ephemeral Key for Protection

   The shared secret allows the server to authenticate the client and
   the ephemeral key allows the server to use a different key to encrypt
   the server-side generated key for the client.  The shared secret is
   distributed via an out-of-band mechanism that is out-of-scope of this
   document.  Also note that the client needs an identification string
   to allow the server to determine which shared secret is being used.

   When the client provides an ephemeral key to protect the response,
   the client includes the following control attributes in a PKIData
   content type [RFC5272]: Server Key Generation Request control (see
   Section 6.1), Transaction Identifier [RFC5272], Sender Nonce
   [RFC5272], and Identification [RFC5272]. The Server Key Generation
   Request control indicates that the shroudMethod is shroud with public
   key and that the bareKey CHOICE is used (see Section 4.1).  The
   PKIData is encapsulated in an AuthenticatedData content type and the
   password RecipientInfo (i.e., pwri CHOICE) is used [RFC5652].  Note
   that reqSequence, cmsSequence, or otherMsgSequence are not included.
   The following depicts this:

     +-------------------------------------------------------------+
     |AuthenticatedData: ReceipientInfo: pwri                      |
     |+-----------------------------------------------------------+|
     ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)||
     ||         control: TransationID                             ||
     ||         control: SenderNonce                              ||
     ||         control: Identification                           ||
     |+-----------------------------------------------------------+|
     +-------------------------------------------------------------+

   After the server has authenticated the client, the server returns the
   server-generated key and any associated parameters in an Asymmetric



Schaad, et al.          Expires January 31, 2014                [Page 9]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   Key Package content type [RFC5958].  The Asymmetric Key Package is
   then encapsulated within a SignedData and that is encapsulated within
   an EnvelopedData using the key agreement or key transport
   RecipientInfo (i.e., kari or ktri CHOICE).  The EnvelopedData is then
   placed in a PKIResponse cmsSequence [RFC5272] and the following
   controls are included: Transaction Identifier, Sender Nonce,
   Recipient Nonce [RFC5272], and Server Key Generation Response (see
   Section 6.2).  The PKIResponse is then encapsulated in a SignedData
   and the certificate associated with the server-generated key is
   placed in the outer-most SignedData's certificate field [RFC5652].
   The following depicts this:

     +-----------------------------------------------------------+
     |SignedData: Signed by the CA                               |
     |             Client's certificate found here               |
     |+---------------------------------------------------------+|
     ||PKIResponse: control: TransactionID                      ||
     ||             control: SenderNonce                        ||
     ||             control: RecipientNonce                     ||
     ||             control: ServerKeyGenResponse               ||
     ||                                                         ||
     ||             cmsSequence:                                ||
     ||             +------------------------------------------+||
     ||             |EncryptedData: RecipientInfo: kari or ktri|||
     ||             |+----------------------+                  |||
     ||             ||SignedData            |                  |||
     ||             ||+--------------------+|                  |||
     ||             |||AsymmetricKeyPackage||                  |||
     ||             ||+--------------------+|                  |||
     ||             |+----------------------+                  |||
     ||             +------------------------------------------+||
     |+---------------------------------------------------------+|
     +-----------------------------------------------------------+

2.3. Certificate for Authentication and Ephemeral Key for Protection

   This scenario differs from the scenarios in Sections 2.1 and 2.2 in
   that the client encapsulates the PKIData in a SignedData instead of
   an AuthenticatedData (i.e., the client uses its private key
   associated with its signature-capable certificate to sign the
   PKIData) but is similar to Section 2.2 for the response.  As implied
   in [RFC5272], clients omit the Identification and Identity Proof
   controls when using certificates to support digital signature
   authentication.  A client requesting a certificate for a different
   name includes the Change Subject Name attribute to ensure the server
   will not reject the request because the name in the certificate used
   to sign the request does not match the name in the request.




Schaad, et al.          Expires January 31, 2014               [Page 10]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   When the client generates their request, the client includes the
   following control attributes in a PKIData content type [RFC5272]:
   Server Key Generation Request (see Section 6.1), Transaction
   Identifier [RFC5272], and Sender Nonce [RFC5272]. The Server Key
   Generation Request control indicates the shroudMethod is shroud with
   public key and the bareKey CHOICE is used (see Section 4.1).  The
   PKIData is encapsulated in a SignedData content type [RFC5652].  Note
   that reqSequence, cmsSequence, and otherMsgSequence are not included
   in the PKIData for the server-side key generation request.  The
   following depicts this:

     +--------------------------------------------------------------+
     |SignedData: Signed by the Client                              |
     |+------------------------------------------------------------||
     ||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey) ||
     ||         control: TransationID                              ||
     ||         control: SenderNonce                               ||
     |+------------------------------------------------------------+|
     +--------------------------------------------------------------+

   After the server has authenticated the client, the server returns the
   server-generated key and any associated parameters in an
   AsymmetricKeyPackage content type [RFC5958].  The
   AsymmetricKeyPackage is then encapsulated within a SignedData and
   that is encapsulated within an EnvelopedData using the key agreement
   or key transport RecipientInfo (i.e., kari or ktri CHOICE).  The
   EnvelopedData is then placed in a PKIResponse cmsSequence [RFC5272]
   and the following controls are included: Transaction Identifier,
   Sender Nonce, Recipient Nonce [RFC5272], and Server Key Generation
   Response (see Section 6.2).  The PKIResponse is then encapsulated in
   a SignedData and the certificate associated with the server-generated
   key is placed in the outer-most SignedData's certificate field
   [RFC5652].  The following depicts this:

     +-----------------------------------------------------------+
     |SignedData: Signed by the CA                               |
     |             Client's certificate found here               |
     |+---------------------------------------------------------+|
     ||PKIResponse: control: TransactionID                      ||
     ||             control: SenderNonce                        ||
     ||             control: RecipientNonce                     ||
     ||             control: ServerKeyGenResponse               ||
     ||                                                         ||
     ||             cmsSequence:                                ||
     ||             +------------------------------------------+||
     ||             |EnvelopedData: RecipientInfo: kari or ktri|||
     ||             |+----------------------+                  |||
     ||             ||SignedData            |                  |||



Schaad, et al.          Expires January 31, 2014               [Page 11]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


     ||             ||+--------------------+|                  |||
     ||             |||AsymmetricKeyPackage||                  |||
     ||             ||+--------------------+|                  |||
     ||             |+----------------------+                  |||
     ||             +------------------------------------------+||
     |+---------------------------------------------------------+|
     +-----------------------------------------------------------+

2.4. Certificate for Authentication and Key Protection

   If a client already has been issued a signature-capable certificate,
   then it can use this certificate to authenticate the requests.  If
   the certificate also indicates support for encryption (i.e., the key
   usage extension is set to keyEncipherment or keyAgreement), then the
   client can request that the server use the same certificate to
   protect the server-generated key (see Section 2.4.1).  If the
   certificate does not indicate support for encryption, then the client
   can provide the server with another certificate to use to encrypt the
   server-generated key (see Section 2.4.2).  The certificate that
   protects the server-generated key MUST be encryption-capable.

   These scenarios differ from the scenarios in Section 2.3 in that the
   response is protected with a previously certified key instead of an
   ephemeral key.  As specified in [RFC5272], clients omit the
   Identification and Identity Proof controls when using certificates to
   support digital signature authentication.  A client requesting a
   certificate for a different name includes the Change Subject Name
   attribute to ensure the server will not reject the request because
   the name in the certificate used to sign the request does not match
   the name in the request.

2.4.1.  Same Certificate for Authentication and Key Protection

   This scenario is the same as in Section 2.3. except Server Key
   Generation Request control includes the certificate CHOICE instead of
   the bareKey CHOICE.

2.4.2.  Different Certificates for Authentication and Key Protection

   When the client's certificate that is used to sign the PKIData does
   not support encryption but the client has another certificate that
   does, the client can include this other certificate in the Server Key
   Generation Request control's certificate field.  When using two
   certificates, the names in the two certificates MUST match to ensure
   the CA will not reject the request due to name mismatches.

2.5.  RA Scenarios




Schaad, et al.          Expires January 31, 2014               [Page 12]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   In Sections 2.1-2.4, client-to-CA protocol flows were illustrated
   where the CA generates the client's key and no RA was involved.  This
   section illustrates client-to-RA-to-CA protocol flows. The scenarios
   divide into two basic categories, according to whether the RA or the
   CA generates the key pair.

   When the RA generates the key on behalf of the client, the RA
   effectively becomes a proxy for the client from the CA's perspective.
    The protocol exchange between the RA and CA is identical to other
   situations in which a client requests a certificate.  This means that
   the CA need not know about or support the Server Key Generation
   Request and Server Key Generation Response controls.  The PKIResponse
   to the client now has to accommodate the fact that the asymmetric key
   package is generated by the RA, whereas the certificate is generated
   by the CA.  This necessitates that the RA intercepts whatever
   response the CA returns to get the client's certificate and that the
   RA generates a signed response that includes the asymmetric key
   package as well as the client's certificate.  See section 9 for
   security considerations.

   When the RA participates in the process but does not generate the
   key, there are two possibilities.  If the RA does not contribute to
   the protocol (its effects may be procedural or out-of-band), then it
   can simply pass the messages it receives to the other party when
   warranted.  If that is not warranted, the RA would generate the usual
   response for the associated failure.  No message flow for this
   possibility is included.  Alternatively, the RA may be responsible
   for processing certain aspects of the request, and needs to vouch for
   that when forwarding the client request to the CA.  The RA does this
   per [RFC5272] by embedding the client request in a Full PKI Request
   that it signs, containing controls for the processing that it
   performs.  Here as in Sections 2.1-2.4, the CA needs to fully
   understand and support the Server Key Generation Request and Server
   Key Generation Response controls, since the CA has to generate the
   key and construct the asymmetric key package.

   In the figures that follow, SKGReq is the Server Key Generation
   Request control (see Section 6.1), the SKGRes denotes the Server Key
   Generation Response control (see Section 6.2), TransactionId denotes
   the Transaction Identifier control [RFC5272], SenderNonce denotes the
   Sender Nonce control [RFC5272], RecipientNonce denotes the Recipient
   Nonce control [RFC57272].  AKP denotes an Asymmetric Key Package
   [RFC5958] (i.e., the private key).  Also, {} denotes encryption
   (i.e., EnvelopedData), <> denotes signatures (i.e., SignedData), with
   () identifying some of the information in carried in unsignedAttrs
   for  clarity, and [] denotes authentication (i.e., SignedData or
   AuthenticatedData).  control denotes controlSequence, reqSeq denotes
   requestSequence, and cmsSeq denotes cmsSequence.  PKCS#10 [RFC2986]



Schaad, et al.          Expires January 31, 2014               [Page 13]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   and CRMF (Certificate Request Message Format) [RFC4211] are the
   certification requests.

2.5.1.  RA-Generated Key Scenarios

   There are some differences in the protocol flows when an RA generates
   the key:

     o The RA MUST be issued a certificate from the CA.  This means all
       of the RA-generated PKIData are encapsulated in a SignedData.
       Further, the RA's certificate can be used for identification and
       linking identity and POP information.

     o The RA generates the certification request for the client by:

       * Using the name from the certificate for the key the RA will use
         to sign the PKIData.

       * Using the information from the client's request.

       * The RA includes the Change Subject Name control [RFC6402]
         either in the PKCS #10 or CRMF TaggedRequest because the POP
         and identity linking CMC requirements are that the name in the
         certificate used to sign the PKIData matches the name in the
         certification request.  The Change Subject Name attribute
         allows the names to be different.

       * Modifying the information as necessary.  Notably adding the
         public key but also adding certificate extensions, etc.  Note
         that the Modify Certificate Template control is not needed as
         the RA is generating a new PKIData.

       * Generating the POP information for the RA-generated keys.  For
         keys that support digital signatures, the RA includes the
         POPSigningKey in the CRMF or the signature in the PKCS #10.
         For encryption-only keys, the RA can indicate that it performed
         POP by including the RA POP Witness control.  Note the CA could
         force the RA to prove it has possession of the key with the
         encrypted/decrypted POP mechanism for [RFC57272], but this adds
         additional round trips and is discussed later in this section.

       * Signing the certification request (i.e., the PKIData) with the
         RA's private key.

   The RA can also generate bulk requests (i.e., include more than one
   request in cmsSequence) with the Bulk Request control [RFC5272] but
   these controls are not depicted in the following sections to simplify
   the protocol flows.  When the RA is requesting more than one key for



Schaad, et al.          Expires January 31, 2014               [Page 14]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   a given client, the RA includes each request in the reqSequence.

   The following message flow applies when the RA generates the key.  It
   supports all of the previously defined choices for authentication and
   shrouding.  The diagram below depicts use of a shared secret for
   authentication by including the Identification control and
   encapsulating the client's PKIData in an AuthenticatedData.  If a
   digital signature is used for authentication, the Identification
   control is omitted and the client encapsulates its PKIData in a
   SignedData.

    Client               RA                                      CA
      |                  |                                       |
      |----------------->|                                       |
      | [PKIData         |                                       |
      | control: SKGReq, |                                       |
      | TransactionID,   |                                       |
      | SenderNonce,     |                                       |
      | Identification]  |                                       |
      |                  |-------------------------------------->|
      |                  | <PKIData                              |
      |                  | control: TransactionId, SenderNonce,  |
      |                  | reqSeq:* PKCS #10 or CRMF>            |
      |                  | (RA signed)                           |
      |                  |<--------------------------------------|
      |                  | <PKIResponse
      |                  | control: TransactionId, SenderNonce,
      |                  | RecipientNonce>
      |<-----------------| (CA signed with issued client certificate)
      | <PKIResponse
      | control: TransactionId, SenderNonce, RecipientNonce, SKGRes
      | cmsSeq: {<AKP>}>
      | (RA signed PKIResponse with CA-issued client certificate)

   *  Includes ChangeSubjectName attribute in PKCS #10 or CRMF.

   NOTE: There's no need for the RA to provide the SKGReq or the {<AKP>}
   to the CA.  The CA won't be able to access the contents of the
   {<AKP>} because it's encrypted for the client and the CA's response
   is always returned to the RA because the RA needs to provide the
   generated {<AKP>} back to the client.

   Whether the client's PKIData is encapsulated in a SignedData or
   AuthenticatedData depends on whether the client used a certificate or
   shared secret for authentication, respectively.  Additionally, the
   RecipientInfo for the EnvelopedData encapsulating the <AKP> depends
   on whether the key was protected with a shared secret (pwri),
   ephemeral key (ktri or kari), or certificate (ktri or kari).



Schaad, et al.          Expires January 31, 2014               [Page 15]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   The RA intercepts the response from the CA; it strips the CA's
   signature and creates a new PKIResponse for the client.  The
   controlSequence is comprised of the Transaction Identifier and
   Recipient Nonce fields from the client's request, the RA's Sender
   Nonce, and the Server Key Generation Response (see Section 6.2); the
   cmsSequence includes the RA-generated {<AKP>}; and the RA signs the
   PKIRepsonse and includes the client's certificate, which was returned
   in the CA's SignedData.

   When the RA is generating an encryption-only key pair for the client,
   and the CA wishes to force the RA to prove it has possession of the
   private key, but the RA cannot use it to generate a one-time
   signature, then the flow is as follows:

    Client               RA                                    CA
      |                  |                                        |
      |----------------->|                                        |
      | [PKIData         |                                        |
      | control: SKGReq, |                                        |
      | TransactionID,   |                                        |
      | SenderNonce,     |                                        |
      | Identification]  |                                        |
      |                  |--------------------------------------->|
      |                  | <PKIData                               |
      |                  | control: TransactionId, SenderNonce,   |
      |                  | RAPOPWitness                           |
      |                  | reqSeq:* PKCS #10 or CRMF>             |
      |                  |<---------------------------------------|
      |                  | <PKIResponse                           |
      |                  | control: CMCStatusInfoV2 (popRequired),|
      |                  | TransactionId, SenderNonce,            |
      |                  | RecipientNonce, EncryptedPOP>          |
      |                  |--------------------------------------->|
      |                  | <PKIData                               |
      |                  | control: TransactionId, SenderNonce,   |
      |                  | RecipientNonce, DecryptedPOP>          |
      |                  |<---------------------------------------|
      |                  | <PKIResponse
      |                  | control: TransactionId, SenderNonce,
      |<-----------------| RecipientNonce>
      | <PKIResponse
      | control: TransactionId, SenderNonce, RecipientNonce, SKGRes
      | cmsSeq: <{<AKP>}>>

   *  Includes ChangeSubjectName attribute in PKCS #10 or CRMF.

   NOTE: The number of round trips between the RA and CA in the above
   figure is twice as many as the first figure in this Section and in



Schaad, et al.          Expires January 31, 2014               [Page 16]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   Section 2.5.1.1; however, the additional round trip is specified in
   [RFC5272] (i.e., this document does not introduce the additional
   round trip).  The additional round trip is necessary when the CA
   forces the RA to perform POP with the CA.  While the additional round
   trip might be problematic between the client and server, the quality
   of communication connectivity between RA and CA should not make the
   additional round trips as problematic as between clients and RAs or
   CAs.

2.5.2.  RA-Involved Scenarios

   This section illustrates a message flow for when the CA generates the
   client's key.  Here too the RA MUST be issued a certificate from the
   CA, which means that all of the RA-generated PKIData are encapsulated
   in a SignedData.  Further, the RA's certificate can be used for
   identification and linking identity and POP information and the RA
   can include the RA Identity Witness control to tell the CA that it
   performed the client identity checks; the RA will omit the control if
   it does not perform these checks.

   The RA can include a Modify Certification Request control [RFC5272]
   in the PKIData that encapsulates the client's request but these
   controls are not shown below.  The RA does this when it wishes to
   modify the request present in the Server Key Generation Request
   control.  The RA MUST NOT use the RA POP Witness control if the CA is
   to generate the key.  This control indicates that the RA performed
   POP, but the key for which POP is claimed has not yet been generated.

   The diagram below depicts the client's use of a shared secret for
   authentication by including the Identification control and
   encapsulating the client's PKIData in an AuthenticatedData.  If a
   digital signature is used for authentication, the Identification
   control is omitted and the client's PKIData is encapsulated in a
   SignedData.  The RA encapsulates the client's request in its PKIData
   by placing the client request in the cmsSequence, and includes
   controls such as Transaction Identifier and Sender Nonce controls as
   well as RA Identity Witness control if the RA checks the client's
   identity.

    Client               RA                                      CA
      |                  |                                        |
      |----------------->|                                        |
      | [PKIData         |                                        |
      | control: SKGReq, |                                        |
      | TransactionID,   |                                        |
      | SenderNonce,     |                                        |
      | Identification]  |                                        |
      |                  |--------------------------------------->|



Schaad, et al.          Expires January 31, 2014               [Page 17]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


      |                  | <PKIData                               |
      |                  | control: TransactionId, SenderNonce,   |
      |                  | RAIdentityWitness                      |
      |                  | cmsSeq: [PKIData                       |
      |                  |  control: SKGReq, TransactionID,       |
      |                  |           SenderNonce, Identification]>|
      |                  |<---------------------------------------|
      |                  | <PKIResponse
      |                  | control: TransactionId, SenderNonce,
      |                  | RecipientNonce
      |                  | cmsSeq: <PKIResponse
      |                  |  control: TransactionID, SenderNonce,
      |                  |           RecipientNonce, SKGRes
      |                  |  cmsSeq: {<AKP>} >
      |                  |  (CA signed with issued client certificate)
      |<-----------------|  > (CA signed)
      | <PKIResponse
      | control: SKGRes, TransactionId, SenderNonce, RecipientNonce
      | cmsSeq: {<AKP>}>
      | (CA signed with issued client certificate)

   When the RA receives the request from the CA, it strips the CA's
   response for the RA off and passes the inner response to the client
   unchanged.  The difference between this scenario and the scenarios in
   Section 2.5.1 is that the signature on the PKIResponse is generated
   by the CA not the RA.

   Note that the additional round trips to prove possession of an
   encryption-only key depicted in Section 2.5.1 are unnecessary here
   because the CA generates the asymmetric key pair and it does not need
   to prove to itself that it has the keys.

3. Generating PKIData and PKIResponse

   [RFC5272] defines PKIData as follows (included here for convenience):

     PKIData ::= SEQUENCE {
       controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
       reqSequence       SEQUENCE SIZE(0..MAX) OF TaggedRequest,
       cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
       otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg
       }

   [RFC5272] defines PKIResponse as follows (included here for
   convenience):

     PKIResponse ::= SEQUENCE {
       controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,



Schaad, et al.          Expires January 31, 2014               [Page 18]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


       cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
       otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg
       }


3.1.  Client Requests

   When the client generates their request, the Server Key Generation
   Request control (see Section 6.1) is included in controlSequence; the
   other sequences (i.e., reqSequence, cmsSequence, and
   otherMsgSequence) are omitted.  If a shared secret is used for
   authentication, the Identification control [RFC5272] is included in
   the controlSequence to ensure that the server can locate the shared-
   secret needed to authenticate the request.  Additional controls can
   be included in controlSequence such as Sender Nonce and Transaction
   Identifier [RFC5272].  The reqSequence, which is included for client-
   generated key certification requests, is not needed as the Server Key
   Generation Request control includes the certification request.  The
   client's request is either encapsulated in an AuthenticatedData or a
   SignedData depending on whether the client is using a shared secret
   or a digital signature key to authenticate the request.  If the
   client wishes to request a certificate with a different name than the
   one that is present in the certificate that authenticates the
   request, the client includes the Change Subject Name control
   [RFC6402] to ensure the server will not reject the request because
   the name in the certificate used to sign the request does not match
   the name in the request.

3.2.  RA Processing of Client Requests

   If an RA is involved, then it can do the following:

     o Forward the request as-is to the CA.  This happens when the CA
       authenticates the request, performs the Identity checks, and
       generates the keys.

     o Not authenticate the request and place one or more client PKIData
       in cmsSequence; reqSequence and otherMsgSequence are omitted.
       Here the RA does not have the shared secret necessary to
       authenticate the request.  The RA can also include additional
       controls in controlSequence such as the Modify Certification
       Request control if the RA needs to modify the client's request
       and the Sender Nonce and Transaction Identifier controls for
       replay protection and transaction processing.  If the RA performs
       the Identity checks it can include the RA Identity Witness
       control.  After generation of the PKIData, the RA encapsulates it
       in a SignedData as part of the digital signature process.




Schaad, et al.          Expires January 31, 2014               [Page 19]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


     o Authenticate the request and place one or more client PKIData in
       cmsSequence; reqSequence and otherMsgSequence are omitted.  The
       RA can also include additional controls in controlSequence such
       as the Modify Certification Request control if the RA needs to
       modify the client's request in the Server Key Generation Request
       control and Sender Nonce and Transaction Identifier for replay
       protection and transaction control.  If the RA also performs the
       Identity check, it includes the Identity Proof Witness control
       [RFC6402] otherwise it is omitted.  After generation of the
       PKIData, the RA encapsulates it in a SignedData as part of the
       digital signature process.

     o Authenticate the request and generate the client's keys.  When
       the RA generates the client's key, the RA generates a new PKIData
       with a reqSequence; cmsSequence and otherMsgSequence are omitted.
        The RA includes the Change Subject Name attribute, as specified
       in [RFC6402], in the PKCS#10 or CRMF because the name in the
       request will not match the name in the certificate used to
       authenticate the request.  If the RA-generated key is signature-
       capable, POP is provided in the typical fashion (i.e., the
       embedded CRMF or PKCS#10 request includes the POP).   The RA can
       also include additional controls in controlSequence such as
       Sender Nonce and Transaction Identifier.  After generation of the
       PKIData, the RA encapsulates it in a SignedData as part of the
       digital signature process.

     o Reject the client's request and return a PKIResponse with an
       appropriate reason in the CMC Status Information V2 control.
       Additionally, the RA includes Transaction Identifier, Sender
       Nonce, and Recipient Nonce if the request included Transaction
       Identifier and Sender Nonce controls.  The PKIResponse is
       encapsulated in a SignedData as part of the digital signature
       process.  This document defines three error conditions (see
       Section 7):

       * For a Server Key Generation Request control using the
         ShroudWithPublicKey choice of certificate or certIdentifier,
         the RA can check that the certificate provided to protect the
         returned private key validates back to an authorized TA.  If
         the certificate does not validate back to their TA, then the RA
         returns a PKIResponse with a CMC Status Information v2 control
         indicating the request failed with an extendedFailInfo
         indicating badCertificate (see Section 7) encapsulated in a
         SignedData.  Note that the RA performing this check will lessen
         the load on the CA, but it need only be done by the RA when the
         RA is generating the client's keys; when the CA is generating
         the keys technically it's up to the CA to perform this check if
         it receives a CA-generated key request from a client.



Schaad, et al.          Expires January 31, 2014               [Page 20]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


       * For a Server Key Generation Request control using the
         ShroudWithSharedSecret choice and where the RA knows the shared
         secret, the RA will reject the request if the shared secret
         does not match the one on the RA by returning a PKIResponse
         with a CMC Status Information control indicating the request
         failed with an extendedFailInfo indicating badSharedSecret (see
         Section 7) encapsulated in a SignedData.  This is done because
         client authentication failed.

       * For a Server Key Generation Request control that has archiveKey
         set to TRUE, the RA is generating the client's keys, and the RA
         does not support archive, the RA will reject the request by
         returning a PKIResponse with a CMC Status Information v2
         control indicating the request failed with an extendedFailInfo
         indicating archiveNotSupported (see Section 7) encapsulated in
         a SignedData.  If the RA knows the CA also does not support
         archival of keys, the RA, if it wishes, can reject the
         certificate in the same fashion; when the CA is generating the
         keys, technically it is up to the CA to perform this check if
         it receives a CA-generated key request from a client.   Note
         that the RA performing this check will lessen the load on the
         CA, but it need only be done by the RA when the RA is
         generating the client's keys; when the CA is generating the
         keys technically it is up to the CA to perform this check if it
         receives a CA-generated key request from a client.

   RA's can also batch more than one request together, by including each
   client request in a separate cmsSequence or reqSequence (for Simple
   PKI requests) along with a Batch Request control in the RA's
   PKIRequest control field.  After generation of the PKIData, the RA
   encapsulates it in a SignedData as part of the digital signature
   process.

   When verifying SignedData signatures, the RA verifies it back to an
   authorized TA.

3.3.  CA Processing

   Receipt of a PKIResponse with a CMC Status Information control that
   indicates failed results requires an out-of-band mechanism to
   adjudicate the error in order to avoid a loop between the client/RA
   and CA.

   CA processing of requests depends on the number of layers of
   encapsulation:

     o Requests with a single layer of encapsulation will be validated
       back to an authorized TA if they are encapsulated in a SignedData



Schaad, et al.          Expires January 31, 2014               [Page 21]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


       or authenticated with the shared secret if they are encapsulated
       in an AuthenticatedData.  For AuthenticatedData encapsulated
       requests the server locates the necessary shared secret with the
       information found in the Identification control.  For a PKIRequst
       with a reqSequence, the server verifies the POP.  Regardless of
       the encapsulation technique, the server performs the Identity
       checks and processes other controls such as Transaction
       Identifier and Sender Nonce.  If any of these checks fail or
       processing of a control fails, the CA rejects the certification
       request with the appropriate error code, as specified in
       [RFC5272].

     o Requests with multiple layers of encapsulation (i.e., those
       requests that are RA-involved) will first validate the signature
       on the outer SignedData back to an authorized TA and process any
       controls present such as RA Identity Witness, Modify Certificate
       Template, Sender Nonce, and Transaction Identifier, as per
       [RFC5272][RFC6402].  Inner requests are also processed as
       specified in the previous bullet.  Failure to validate back to an
       authorized TA or control processing failures result in rejected
       requests with the appropriate error code, as specified in
       [RFC5752].

   CAs may require that the RA prove that it has possession of
   encryption-only keys that do not support one-time signature use, by
   returning a PKIResponse indicating the request failed because POP is
   required and including the Encrypted POP control along with other
   appropriate controls.  The response is signed by the CA.  See Section
   2.5.1.

   After successfully authenticating the request and verifying the
   client's identity, the CA generates:

     o Responses for single layer encapsulated requests for RA-generated
       keys by issuing the certificate.  If no controls were present in
       the request (see Appendix B), the PKIResponse is a Simple PKI
       Response [RFC5751], which includes no content and therefore no
       signature.  With controls (e.g., Transaction Identifier, Sender
       Nonce, and Recipient Nonce), the PKIResponse includes the
       appropriate controls and is signed by the CA.  The CA places the
       certificate in the SignedData certificates field.

     o Responses for multi-layered encapsulation requests for RA-
       generated keys (See Appendix B) beginning with the previous
       bullet followed by placing the inner response in a cmsSequence
       entry.  The outer PKIResponse includes the Batch Response control
       as well as any other necessary controls in controlSequence and
       the CA generates a signature for the SignedData.



Schaad, et al.          Expires January 31, 2014               [Page 22]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


     o Responses for single layer encapsulated requests for CA-generated
       keys by generating the asymmetric key pair and issuing the
       certificate.  The signed CA-generated PKIResponse includes the
       Server Key Generation Response control (see Section 6.2) along
       with other controls based on whether they were present in the
       controlSequence as well as the signed and then encrypted
       Asymmetric Key Package in cmsSequence.  The CA places the
       certificate in the SignedData certificates field.

     o Responses for multi-layered encapsulation requests for CA-
       generated keys beginning with the previous bullet followed by
       encapsulating the inner response in cmsSequence.  The outer
       response includes controls as necessary in controlSequence and
       the CA generates a signature.

   If the CA is unable to perform the request at this time or the entire
   request cannot be processed, it can return a signed PKIResponse
   indicating with a CMC Status Information  control with a status of
   pending or partial along with pendInfo, which the client uses to know
   when to ask the CA next about the request.

   When the CA fails to or refuses to process the request, it returns a
   PKIResponse with a CMC Status Information control with the
   appropriate error code from [RFC5272] or from Section 7 of this
   document.  Additionally, it includes Transaction Identifier, Sender
   Nonce, and Recipient Nonce in the response if the request included
   Transaction Identifier and Sender Nonce controls.

3.4.  RA Processing of CA Responses

   If the CA rejected the RA's request as indicated by a PKIResponse
   with CMC Status Information control that is failed, then an out-of-
   band mechanism may be necessary to determine the cause of failure in
   order to avoid a loop of the RA returning the same request at a later
   time only to also have it rejected.

   If the CA returned a pending or partial response, the RA will use the
   information in the CMC Status Information control's pendInfo to poll
   the CA with a signed PKIRequest with a Query Pending control.  CA
   processing continues as in Section 3.3.

   RA's that are challenged by the CA to prove possession of an
   encryption-only RA-generated key validate the CA's signature back to
   an authorized TA, decrypt the POP, and process any other controls
   that are present.  If any of these fail, then the RA terminate the
   request and inform the operator of the fault.  Assuming the checks
   pass, the RA generates a PKIData that includes a Decrypted POP
   control and any other controls with no cmsSequence, reqSequence, or



Schaad, et al.          Expires January 31, 2014               [Page 23]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   otherMsgSequence.  The RA encapsulates the PKIData or the PKIResponse
   in a SignedData as part of the digital signature process and sends it
   to the CA.  CA processing resumes as in Section 3.3.

   Assuming the response is a success:

     o If there is no signature, either the keys are RA-generated or are
       client-generated.  If the keys are client-generated, then the RA
       returns the message to the client unmodified.  If the key is RA-
       generated, the RA generates a PKIResponse for the client that
       includes the signed and then encrypted Asymmetric Key Package in
       cmsSequence (see Section 5), the Server Key Generation Response
       control (see Section 6.2), and any other controls.  Finally, the
       RA encapsulates the PKIResponse for the client in a SignedData as
       part of the digital signature process and includes the client's
       certificate (from the CA) in the SignedData's certificate field.

     o If there is a signature:

       * The response is for an RA-generated key request that contained
         controls and the RA knows this by the presence of the
         Transaction Identifier, Sender Nonce, or Recipient Nonce
         controls (and possibly other controls) but there is no
         cmsSequence or CMC Status Information control indicating the
         request failed or is pending.  The RA generates a PKIResponse
         for the client that includes the signed and then encrypted
         Asymmetric Key Package in cmsSequence (see Section 5), the
         Server Key Generation Response control (see Section 6.2), and
         any other controls as appropriate.  Finally, the RA
         encapsulates the PKIResponse for the client in a SignedData as
         part of the digital signature process and includes the client's
         certificate from the CA's response in the RA's SignedData
         certificate field.

       * The response is for a request where the CA generated the key
         and the RA knows this by the presence of a cmsSequence element.
          The RA processes any controls and assuming the processing
         passes the RA strips off the outer SignedData and forwards the
         cmsSequence element (i.e., the SignedData) to the client.

       * The response is for a batch request and the RA knows this by
         the presence of a Batch Response control.  The RA process any
         controls and assuming the processing passes the RA strips off
         the outer SignedData and forwards the inner SignedData(s) from
         the cmsSequence to the appropriate clients.  If any of the
         requests are marked as failed or pending, then the processing
         earlier in this section applies.




Schaad, et al.          Expires January 31, 2014               [Page 24]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   The RA, if it wishes, can also check the returned certificate to make
   sure it validates back to an authorized TA and that the returned
   certificate is consistent with the certificate request found in the
   Server Key Generation Request control.   These checks cut down on
   errors at the client.  If the RA detects that the certificate is not
   consistent, the SHOULD NOT return the certificate to the client and
   the RA SHOULD request that the certificate be revoked.

   RA-generated keys for which a PKIResponse with a CMC Status
   Information control that is not success SHOULD NOT return the Server
   Key Generation Response or the encapsulated Asymmetric Key Package to
   the client because the the CA didn't certify the public key.

3.4.  Client Processing of Responses

   Clients validate the signature on all responses back to an authorized
   TA.

   Responses signed by an RA with a client certificate signed by a CA
   whose certificate includes a id-kp-cmcCA EKU (Extended Key Usage)
   [RFC6402] will violate the should requirement found in [RFC6042] that
   the PKIResponse be signed with an entity with the same name as the
   certificate.  Because the RA has generated the keys there are many
   more bad things an RA can do so this seemed like a tradeoff worth
   making.

4. Shrouding Algorithms

   For the server-side key generation control attribute described in
   this document to function, clients need to tell the server in advance
   what encryption algorithm and what key value is to be used for
   encrypting the returned private key.  The encrypted data returned is
   returned as an EnvelopedData object as defined by [RFC5652] and
   placed in the cmsSequence field of a PKIResponse [RFC5272].  Clients
   also need to tell the server in advance what digital signature and
   hash algorithms it supports to ensure the certification response and
   certificate can be verified.

   Each request control for which the response includes encrypted data
   contains two fields to define type of encryption used:
   algCapabilities and shroudMethod.

   The algCapabilities field, see Section 6.1, contains the advertised
   capabilities of the client-side entity.  This field uses the S/MIME
   Capabilities type defined in section 2.5.2 of [RFC5751].  The
   capabilities to be listed are digital signature algorithms, message
   digest algorithms, content encryption algorithms, key agreement
   algorithms, key encipherment algorithms, key-wrap algorithms and key



Schaad, et al.          Expires January 31, 2014               [Page 25]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   derivation algorithms.  Encodings for SMIME Capability values for
   Elliptic Curve Key Agreement, Key Derivation Function, and Key Wrap
   algorithms can be found in [RFC5753], Message Digest and Signature
   algorithms can be found in [RFC5754], and AES Key Wrap with Padding
   can be found in [RFC5959].

   The shroudMethod field, see Section 6.1, defines the method by which
   the server will do the key management of the content encryption key
   (CEK) value in  EnvelopedData.  The shroudMethod field uses the type
   ShroudMethod.  This type is defined as:

     ShroudMethod ::= AlgorithmIdentifier {
       SHROUD-ALGORITHM, { ShroudAlgorithmSet }
       }

   When a new shroud method is defined it includes (a) the source of the
   key material, (b) the public or salting information, and (c) the
   method of protecting the Content Encryption Key (CEK) using the
   requested data, source key material and salt.  This document defines
   two shroud methods: id-cmc-shroudWithPublicKey and id-cmc-
   shroudWithSharedSecret.  Clients and servers MUST support id-cmc-
   shroudWithPublicKey.  Client and servers SHOULD support id-cmc-
   shroudWithSharedSecret.

   Other shrouding methods could be defined in the future that would not
   involve the use of EnvelopedData.  For example, one could conceive of
   a shrouding method that required the use of Transport Layer Security
   (TLS) [RFC5246] to provide the necessary security between the server
   and the client.  This document does not define any such mechanism.

4.1. Shroud With a Public Key

   Clients can indicate that the server use a public key, either wrapped
   in a certificate or as a bare public key, to protect the server-
   generated key.  For this option, the key material is either included
   or referenced by a key identifier.  The following object identifier
   identifies the shroudWithPublicKey shroud method:

     id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= { id-cmc XX }

   shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey:

     srda-shroudWithPublicKey SHROUD-ALGORITHM ::= {
        IDENTIFIED BY id-cmc-shroudWithPublicKey,
        PARAMS TYPE ShroudWithPublicKey ARE required,
        SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithPublicKey }
        }




Schaad, et al.          Expires January 31, 2014               [Page 26]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


     ShroudWithPublicKey ::= CHOICE {
       certificate         Certificate,
       certIdentifier  [1] SignerIdentifier,
       bareKey         [2] SEQUENCE {
         publicKey  SubjectPublicKeyInfo,
         ski        SubjectKeyIdentifier
         }
       }

   The fields of type ShroudWithPublicKey have the following meanings:

     o certificate provides a public key certificate containing the
       public key to be used for encrypting the server-generated private
       key from the server to the client.

     o certIdentifier provides a pointer to a public key certificate
       located in the SignedData that encapsulates the client's PKIData.

       For the above two fields, servers SHOULD check that the subject
       and subject alternative names match in some way with the entity
       that the private key is destined for.

     o bareKey allows for an arbitrary public key to be used to return
       the encrypted private key.

       - publicKey contains the public key that is to be used for
         encrypting the private key returned from the server to the
         client.

       - ski contains the SubjectKeyIdentifier that will be used in CMS
         EnvelopedData to identify the public key when encrypting the
         private key from the server to the client.

   When this method is used with the certificate option, the server
   validates the certificate back to a trust anchor.  Further, the
   server checks that the client provided certificate belongs to the
   same client that authenticated the certification request (e.g. the
   certificate subjects match, or the client provided certificate
   belongs to the same entity as the authentication shared secret).  If
   either of these checks fails, then the server returns a CMCFailInfo
   with the value of badCertificate, which is defined in Section 7.

4.2. Shroud With a Shared-Secret Key

   Clients can indicate that servers use a shared secret value to
   protect the server-generated private key.  For this option, the key
   material is identified by the identifier, the key derivation
   algorithms supported by the client are included in the



Schaad, et al.          Expires January 31, 2014               [Page 27]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   algCapabilities field.  No salting material is provided by the
   client.  The derived key is then used as a key encryption key in the
   EnvelopedData recipient info structure. The following object
   identifier identifies the shroudWithSharedSecret control attribute:

     id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX}

   shroudWithSharedSecret attribute values have the ASN.1 type
   ShroudWithSharedSecret:

     shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= {
       IDENTIFIED BY id-cmc-shroudWithSharedSecret
       PARAMS TYPE ShroudWithSharedSecret ARE required
       SMIME-CAPS { IDENTIFIED BY id-cmc-shroudWithSharedSecret }
       }

     ShroudWithSharedSecret ::= UTF8String

   The common identification string for the client and the server is
   placed in the ShroudWithSharedSecret field, which is a UTFString
   [RFC5280].  In addition the client needs to place both a key
   derivation function and a key wrap function in the set of
   capabilities advertised by the client in the algCapabilities field.
   The identification string is used to identify the pass phrase or
   shared key.

   When this method is used, the server checks that the chosen shared
   secret belongs to the authenticated identity of the entity that
   generated the certification request.  If this check fails, then the
   server returns a CMCFailInfo with the value of badSharedSecret, which
   is defined in Section 7.  In general, while it is expected that the
   same identity token and shared secret used to do the identity
   authentication are used to derive the key encryption key this is not
   required.

5. Returned Key Format

   The server returns the private key and optionally the corresponding
   public key to the client with the AsymmetricKeyPackage content type
   [RFC5958].  The AsymmetricKeyPackage is first encapsulated in a
   Cryptographic Message Syntax (CMS) SignedData content type [RFC5652],
   then the inner SignedData is further encapsulated in an EnvelopedData
   content type [RFC5652], and finally the EnvelopedData is encapsulated
   in an outer SignedData.  The Content Hints attribute [RFC2634] can be
   used in the outer SignedData to provide a hint as to the inner most
   content type (i.e., the AsymmetricKeyPacakge).   There MUST be only
   one OneAsymmetricKey present in the AsymmetricKeyPackage sequence.
   When more than one private key is to be returned, multiple



Schaad, et al.          Expires January 31, 2014               [Page 28]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   AsymmetricKeyPackage content types are needed.  For example, when
   returning more than one private key the separate AsymmetricKeyPackage
   content types can be individually encapsulated in SignedData,
   packaged together with the ContentCollection content type [RFC4073],
   protected with an EnvelopedData around the ContentCollection, and
   finally the EnvelopedData is encapsulated in a SignedData.  The
   public key SHOULD be included in the AsymmetricKeyPackage.

6. Server-Side Key Generation

   This section provides the control attributes necessary for doing
   server-side generation of keys for clients.  The client places the
   request for the key generation in a request message and sends it to
   the server.  The server will generate the key pair, create a
   certificate for the public key and return the data in a response
   message, or the server will return a failure indication.

6.1. Server-Side Key Generation Request Attribute

   The client initiates a request for server-side key generation by
   including the server-side key generation request attribute in the
   control attributes section of a PKIData object.  The request
   attribute includes information about how to return the generated key
   as well as any client suggested items for the certificate.  The
   control attribute for doing server-side key generation is identified
   by the following OID:

     id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX }

   The Server-Side Key Generation Request control attribute has the
   following ASN.1 definition:

     cmc-serverKeyGenRequest CMC-CONTROL ::= {
       ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest
       }

     ServerKeyGenRequest ::= SEQUENCE {
       certificateRequest  CertTemplate,
       shroudMethod        ShroudMethod,
       algCapabilities     SMimeCapabilties OPTIONAL,
       archiveKey          BOOLEAN DEFAULT TRUE
       }

   The fields in ServerKeyGenRequest have the following meaning:

     o certificateRequest contains the data fields that the client
       suggests for the certificate being requested for the server
       generated key pair.  The format is TaggedRequest from [RFC5272],



Schaad, et al.          Expires January 31, 2014               [Page 29]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


       which supports both PKCS#10 and CRMF requests.

     o shroudMethod contains the identifier of the type of algorithm to
       be used in deriving the key used to encrypt the private key.

     o algCapabilities contains the set of algorithm capabilities being
       advertised by the client.  The server uses algorithms from this
       set in the ServerKeyGenResponse object to encrypt the private key
       of the server-generated key pair.  This field is optional because
       this information might be carried in a signed attribute, included
       within a certificate or be part of the local configuration.

     o archiveKey is set to TRUE if the client wishes the key to be
       archived as well as generated on the server.  Further processing
       by the server when this is set to TRUE is out-of-scope.

   The client can request that the generated key be for a specific
   algorithm by placing data in the publicKey field of the CRMF request
   or in the subjectPKInfo of the PKCS#10 request.  If the publicKey
   field is populated, then the public key is a zero length bit string.
   If the client requests a specific algorithm, the server either
   generates a key for that algorithm (with the parameters if defined)
   or fails to process the request.  If the request fails for this
   reason, the server returns a CMCFailInfo with a value of badAlg
   [RFC5272].

   As specified in [RFC5272]:

      "A server is not required to use all of the values suggested by
      the client in the certificate template.  Servers MUST be able to
      process all extensions defined in [RFC5280].  Servers are not
      required to be able to process other V3 X.509 extensions
      transmitted using this protocol, nor are they required to be able
      to process other, private extensions.  Servers are permitted to
      modify client-requested extensions.  Servers MUST NOT alter an
      extension so as to invalidate the original intent of a client-
      requested extension.  (For example change key usage from key
      exchange to digital signature.)  If a certification request is
      denied due to the inability to handle a requested extension, the
      server MUST respond with a CMCFailInfo with a value of
      unsupportedExt."

   A server that does not recognize the algorithm identified in
   shroudMethod will reject the request.  The server returns a
   CMCFailInfo with a value of badAlg [RFC5272].

   A server that does not support at least one of the algCapabilities
   will reject the request.  The server returns a CMCFailInfo with a



Schaad, et al.          Expires January 31, 2014               [Page 30]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   value of badAlg [RFC5272].

   If archiveKey is set to true and the server does not support
   archiving of private keys, the request will be rejected by the
   server.  The server returns a CMCFailInfo with a value of
   archiveNotSupported, see Section 7.

6.2. Server-side Key Generation Response

   The server creates a server-side key generation response attribute
   for every key generation request made and successfully completed.
   The response message has a pointer to both the original request
   attribute and to the body part in the current message that holds the
   encrypted private keys.  The response message also can contain a
   pointer to the certificate issued.  The key generation response
   control attribute is identified by the OID:

     id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= { id-cmc XX }

   The Server-Side Key Generation Response control attribute has the
   following ASN.1 definition:

     cmc-serverKeyGenResponse CMC-CONTROL ::= {
       ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse
       }

     ServerKeyGenResponse ::= SEQUENCE {
       cmsBodyPartId          BodyPartID,
       requestBodyPartId      BodyPartID,
       issuerAndSerialNumber  IssuerAndSerialNumber OPTIONAL
       }

   The fields in ServerKeyGenResponse have the following meaning:

     o cmsBodyPartId identifies a TaggedContentInfo contained within the
       enclosing PKIData.  The ContentInfo object is of type
       EnvelopedData and has an encapsulated content of id-ct-KP-
       aKeyPackage (see Section 4).

     o requestBodyPartId contains the body part identifier for the
       server-side key generation request control attribute.  This
       allows for clients to associate the resulting key and certificate
       with the original request.

     o issuerAndSerialNumber if present contains the identity of the
       certificate issued to satisfy the request.  The certificate is
       placed in the certificate bag of the immediately encapsulating
       signedData object.



Schaad, et al.          Expires January 31, 2014               [Page 31]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   As specified in [RFC5272]:

      "Clients MUST NOT assume the certificates are in any order.
      Servers SHOULD include all intermediate certificates needed to
      form complete chains to one or more self-signed certificates, not
      just the newly issued certificate(s) in the certificate bag.  The
      server MAY additionally return CRLs in the CRL bag.  Servers MAY
      include self-signed certificates.  Clients MUST NOT implicitly
      trust included self-signed certificate(s) merely due to its
      presence in the certificate bag."

7. Additional Error Codes

   This section defines ExtendedFailInfo errors from this document:

     cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= {
       TYPE ErrorList IDENTIFIED BY id-tbd
       }

     ErrorList ::= INTEGER {
       archiveNotSupported (1),
       badCertificate (2),
       badSharedSecret (3)
       }

     o archiveNotSupported indicates that the server does not support
       archiving of private keys.  The syntax for the ExtendedFailInfo
       is as follows:

         cmc-err-archiveNotSupport EXTENDED-FAILURE-INFO ::={
           IDENTIFIED BY id-tbd
           }

     o badCertificate indicates that the certificate to be used to
       encrypt the response did not validate back to a RA/CA trust
       anchor or the certificate does not belong to the client. The
       syntax for the ExtendedFailInfo is as follows:

         cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={
           IDENTIFIED BY id-tbd
           }

     o badSharedSecret indicates that the shared secret provided by the
       client does not match that stored by the server.

         cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={
           IDENTIFIED BY id-tbd
           }



Schaad, et al.          Expires January 31, 2014               [Page 32]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


8.  Proof-of-Possession

   Some servers may require that the client prove that it has possession
   of the server-generated key.  This requires an additional roundtrip
   beyond those previously discussed.

   For certificates returned that support digital signatures the process
   is as described in [RFC5272]: the server indicates in CMCStatus is
   confirmRequired, the client returns the Confirm Certificate
   Acceptance control in PKIData signed with the server-generated
   private key, and the server responds with a CMCStatus of success.

   For certificates returned that only support encryption, the server
   indicates the CMCStatus is popRequired and includes the Encrypted POP
   control, the client returns the Decrypted POP control.  Whether the
   PKIRequest from the client is encapsulated in an Authenticated Data
   or Signed Data depends on which mechanism was used during the server
   key generation request.

9. Security Considerations

   Central generation of digital signature keys contains risks and is
   not always appropriate.  Organization-specific CPs (Certificate
   Policies) [RFC3647] define whether or not server-side generation of
   digital signature keys is permitted.

   There is a balance that needs to be maintained between the use of a
   potentially poorly generated one time key and the use of a key
   externally provided.  For externally provided keys, the external
   provider of the key will be able to decrypt the key delivery message
   as long as it was captured. For poorly generated one time keys, any
   external party might be able to guess the key and thus decrypt the
   key delivery message.  Different types of keys will have different
   requirements for what a poorly generated key means. Generators of RSA
   keys need to be able to do good prime checking, generators of Diffie-
   Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) keys only need a
   moderate quality random number generator if the group parameters are
   externally provided.

   This specification requires implementations to generate key pairs and
   other random values [RFC4086].  The use of inadequate pseudo-random
   number generators (PRNGs) can result in little or no security.  The
   generation of quality random numbers is difficult. NIST Special
   Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer
   guidance.

   Private keys, regardless of where they are generated, must be
   appropriately protected from disclosure or modification on the



Schaad, et al.          Expires January 31, 2014               [Page 33]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   server, in transit, and on the client.  Cryptographic algorithms and
   keys used to protect the private key should be at least as strong as
   the private key's intended strength.

   Key agreement algorithms (i.e., Diffie-Hellam or Elliptic Curve
   Diffie-Hellman) can be used to protect the returned server-generated
   key.  These algorithms support a number of different schemes [SP-800-
   56].  Normally, an Ephemeral-Static (E-S) scheme is used (more
   formally known as "(Cofactor) One-Pass Diffie-Hellman,
   C(1e,1s,ECCCDH) Scheme") see [RFC5753], but here the client provides
   an ephemeral key to the server so an S-E scheme is used when the key
   is encrypted for the client.  Regardless, the client needs to
   generate an ephemeral key and provide it to the server and this key
   needs to use the same parameters (i.e., p, q, g for DH and elliptic
   curve for ECDH) as the server.  The client's parameters MUST be
   present in the publicKey or certificate field of the Server Key
   Generation Request control or MUST be in the certificate referred to
   by the ski in the same control.  The client can find the server's
   parameters in the server's certificate; to make it easy on clients,
   server certificates MUST include parameters.    How the client
   obtains the server's certificate is out of scope.

   Servers that support the features specified herein need to document
   their procedures in a CPS (Certificate Practice Statement) [RFC3647].
    CAs that certify server-generated private keys are certifying that
   they've taken due diligence to ensure that the private key is only
   known to and used by the subject.  Depending on the Certification
   Policy [RFC3647], the keys have been allocated to the subject, but
   the keys may not be strictly owned by the subject.  The CA (and the
   enterprise it supports) has a reason for issuing the keys (e.g.,
   employer to employee; school to student) and because the enterprise
   CA generated the private keys it is accountable for the
   trustworthiness of the private key. But, the subject should beware
   using it for other purposes.

   When using an ephemeral key for protecting the server-generated key,
   A compromised signature key, when used by the intended party, will
   not automatically jeopardize the security of the server-generated
   keys.  Procedural controls can help to ensure a one-to-one mapping
   between verified requests and intended parties (i.e. mitigate the
   risk of masquerade using a compromised authentication key and
   certificate), but that is outside the scope of this document.

   POP is important, but for server-generated keys it can only be
   provided after the server-generated key has been returned by the
   client (see Section 8).

   When the shared secret is used to provide client authentication and



Schaad, et al.          Expires January 31, 2014               [Page 34]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   protect the server-generated private key, the shared secret must be
   kept secret for the lifetime of the key.  This is because disclosure
   could allow attackers to determine the server-generated private key.
   This is different than certification requests with client-generated
   keys because the shared secret is no longer needed after the
   authentication.

   If the key generator and the server are not collocated, then the
   exchange between these two entities must be protected from
   unauthorized disclosure and modification and both entities must have
   a trust relationship.  However, these exchanges are beyond the scope
   of this document.  Note that the CA needs access to the public key to
   generate the certificate.  If the key generator encrypts the
   generated key for the client, then the key generator needs to provide
   the public key to the CA (possibly through the RA).

   Returning the key to the wrong client can be bad.  If an encrypted
   key is returned to the wrong client, then it is only bad if the key
   was encrypted for the wrong client and then something much worse is
   afoot.  If the encrypted key is returned to the wrong client and it
   is encrypted for the right client (i.e., it was misdirected), then it
   is bad but the unencrypted key hasn't been disclosed to an
   unauthorized client.  The protection afforded by the confidentiality
   algorithm is what protects the misdirected key from unauthorized
   disclosure.

10. IANA Considerations

   This document makes use of object identifiers to register CMC control
   attributes and CMC error codes.  Additionally, an object identifier
   is used to identify the ASN.1 module found in Appendix A.  All are
   defined in an arc delegated by IANA to the PKIX Working Group. The
   current contents of the arc are located here:

       http://www.imc.org/ietf-pkix/pkix-oid.asn

   They were obtained by sending a request to ietf-pkix-oid-reg@imc.org.
    When the PKIX WG closes, this arc and registration procedures will
   be transferred to IANA. No further action by IANA is necessary for
   this document or any anticipated updates.

11.  References

11.1  Normative References

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




Schaad, et al.          Expires January 31, 2014               [Page 35]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              November 2000.

   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF)", RFC 4211,
              September 2005.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, June 2008.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958, August
              2010.

   [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)
              Updates", RFC 6402, November 2011.


12.2  Informative References

   [FIPS-186] National Institute of Standards and Technology (NIST),
              FIPS 186-3 DRAFT: Digital Signature Standard (DSS),
              November 2008.

   [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
              RFC 2634, June 1999.

   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
              Wu, "Internet X.509 Public Key Infrastructure Certificate
              Policy and Certification Practices Framework", RFC 3647,
              November 2003.

   [RFC4073]  Housley, R., "Protecting Multiple Contents with the
              Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,



Schaad, et al.          Expires January 31, 2014               [Page 36]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


              "Randomness Requirements for Security", BCP 106, RFC 4086,
              June 2005.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", FYI
              36, RFC 4949, August 2007.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", RFC 5753, January 2010.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, January 2010.

   [RFC5959]  Turner, S., "Algorithms for Asymmetric Key Package Content
              Type", RFC 5959, August 2010.

   [SP-800-56] Barker, E., Johnson, D., and M. Smid, "Recommendation for
               Pair-Wise Key Establishment Schemes Using Discrete
               Logarithm Cryptography", NIST Special Publication 800-56A
               Revision 1, March 2007.

   [SP-800-57] National Institute of Standards and Technology (NIST),
               Special Publication 800-57: Recommendation for Key
               Management - Part 1 (Revised), March 2007.

   [SP-800-90] National Institute of Standards and Technology (NIST),
               Special Publication 800-90: Recommendation for Random
               Number Generation Using Deterministic Random Number Bit
               Generators (Revised), March 2007.

Appendix A. ASN.1 Module

   To be supplied later.

Appendix B. Additional Message Flows

   This appendix forms a non-normative part of this specification.

   The main body of this document has portrayed protocol flows with
   optional controls.  This was done to explain the more complicated
   scenarios.  This appendix depicts the flows without those optional
   controls.

   For example the figure in Section 2.5.1 without the TransactionId,
   SenderNonce, and RecipientNonce, appear as follows:



Schaad, et al.          Expires January 31, 2014               [Page 37]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


    Client               RA                                      CA
      |                  |                                       |
      |----------------->|                                       |
      | [PKIData         |                                       |
      | control: SKGReq, |                                       |
      | Identification]  |                                       |
      |                  |-------------------------------------->|
      |                  | <PKIData                              |
      |                  | reqSeq:* PKCS #10 or CRMF>            |
      |                  |<--------------------------------------|
      |<-----------------| PKIResponse
      | <PKIResponse
      | control: SKGRes
      | cmsSeq: {<AKP>}>

   *  Includes ChangeSubjectName attribute in PKCS #10 or CRMF.

   The PKIResponse from the CA is a certs-only message, which does not
   include a signature.

   Likewise for the figure in Section 2.5.2:

    Client               RA                                      CA
      |                  |                                        |
      |----------------->|                                        |
      | [PKIData         |                                        |
      | control: SKGReq, |                                        |
      | Identification]  |                                        |
      |                  |--------------------------------------->|
      |                  | <PKIData                               |
      |                  | control: RAIdentityWitness             |
      |                  | cmsSeq: [PKIData                       |
      |                  |  control: SKGReq, Identification]>     |
      |                  |<---------------------------------------|
      |                  | <PKIResponse
      |                  | cmsSeq: <PKIResponse
      |                  |  control: SKGRes
      |<-----------------|  cmsSeq: {<AKP>} > >
      | <PKIResponse
      | control: SKGRes
      | cmsSeq: {<AKP>}>

   If the RA doesn't perform the Identity checks, then it can forward
   the client's request without the additional layers of encapsulation.

    Client               RA                                      CA
      |                  |                                        |
      |----------------->|                                        |



Schaad, et al.          Expires January 31, 2014               [Page 38]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


      | [PKIData         |                                        |
      | control: SKGReq, |                                        |
      | Identification]  |                                        |
      |                  |--------------------------------------->|
      |                  | [PKIData                               |
      |                  |  control: SKGReq, Identification]      |
      |                  |<---------------------------------------|
      |                  | <PKIResponse
      |                  |   control: SKGRes
      |                  |   cmsSeq: {<AKP>}>
      |<-----------------|
      | <PKIResponse
      | control: SKGRes
      | cmsSeq: {<AKP>}>

   Not to be outdone, the scenarios in Section 2.5.1 can be more
   complicated by an RA that batch requests together.  The following
   depicts a number of clients sending requests together that an RA then
   batches together.  The unsigned PKIResponse (a certs-only message)
   includes all of the certificates issued.  The CA can also return
   individual responses as opposed to batching them all together or it
   can batch them together in some other combination.

    Client(1-n)          RA                                      CA
      |                  |                                       |
      |----------------->|                                       |
      | [PKIData         |                                       |
      | control: SKGReq, |                                       |
      | Identification]  |                                       |
      |                  |-------------------------------------->|
      |                  | <PKIData                              |
      |                  | cmsSeq (1-n):* PKCS #10 or CRMF>      |
      |                  |<--------------------------------------|
      |                  | <PKIResponse
      |                  | control: BatchResponse
      |<-----------------| cmsSeq (1-n): certs-only>
      | <PKIResponse(1-n)
      | control: SKGRes
      | cmsSeq: {<AKP>}>

   *  Includes ChangeSubjectName attribute in PKCS #10 or CRMF.

   In another scenario, all but one of the requests were successfully
   processed.  The RA returns those that were successful back to the
   clients but later polls the CA, based on the value CMCStatusInfoV2
   pendInfo, for the one that was not successful.  The CA returns the
   one successful request.




Schaad, et al.          Expires January 31, 2014               [Page 39]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


    Client(1-n)          RA                                      CA
      |                  |                                       |
      |----------------->|                                       |
      | [PKIData         |                                       |
      | control: SKGReq, |                                       |
      | Identification]  |                                       |
      |                  |-------------------------------------->|
      |                  | <PKIData                              |
      |                  | control: BatchRequest                 |
      |                  | cmsSeq (1-n):* PKCS #10 or CRMF>      |
      |                  |<--------------------------------------|
      |                  | <PKIResponse
      |                  |  control:CMCStatusInfoV2 (partial),
      |                  |  BatchResponse
      |                  |  cmsSeq (1-n): certs-only>
      |<-----------------|
      | <PKIResponse(1-*)|
      | control: SKGRes  |
      | cmsSeq: {<AKP>}> |
      |                  |-------------------------------------->|
      |                  | <PKIData                              |
      |                  | control: QueryPending>                |
      |                  |<--------------------------------------|
      |                  | PKIResponse
      |<-----------------|
      | <PKIResponse
      | control: SKGRes
      | cmsSeq: {<AKP>}>

   *  Includes ChangeSubjectName attribute in PKCS #10 or CRMF.

   Batching the requests can also be performed for CA-generated keys as
   shown below.  The RA Identity Witness controls indicates all those
   client requests that it performed Identity checks on.

    Client               RA                                      CA
      |                  |                                        |
      |----------------->|                                        |
      | [PKIData         |                                        |
      | control: SKGReq, |                                        |
      | TransactionID,   |                                        |
      | SenderNonce,     |                                        |
      | Identification]  |                                        |
      |                  |--------------------------------------->|
      |                  | <PKIData                               |
      |                  | control: TransactionId, SenderNonce,   |
      |                  | RAIdentityWitness, BatchRequest        |
      |                  | cmsSeq (1-n): [PKIData                 |



Schaad, et al.          Expires January 31, 2014               [Page 40]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


      |                  |  control: SKGReq, TransactionID,       |
      |                  |           SenderNonce, Identification]>|
      |                  |<---------------------------------------|
      |                  | <PKIResponse
      |                  | control: TransactionId, SenderNonce,
      |                  | RecipientNonce, BatchResponse
      |                  | cmsSeq (1-n): <PKIResponse
      |                  |  control: TransactionID, SenderNonce,
      |                  |           RecipientNonce, SKGRes
      |<-----------------|  cmsSeq: {<AKP>} >>
      | <PKIResponse(1-n)
      | control: SKGRes, TransactionId, SenderNonce, RecipientNonce
      | cmsSeq: {<AKP>}>


Appendix B. Examples

   To be supplied later.

B.1. Client Requests

B.1.1. Shroud with Certificate

B.1.2. Shroud with Public Key

B.1.3. Shroud with Shared Secret

B.2. CA-Generate Key Response

B.3. RA-Generate Key Response

Authors' Addresses


   Jim Schaad
   Soaring Hawk Consulting

   Email: jimsch@exmsft.com


   Sean Turner
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA 22031
   USA

   Email: turners@ieca.com




Schaad, et al.          Expires January 31, 2014               [Page 41]


I-D              CMC Extensions: Server Key Generation     July 30, 2013


   Paul Timmel
   National Information Assurance Research Laboratory
   National Security Agency

   Email: pstimme@tycho.ncsc.mil














































Schaad, et al.          Expires January 31, 2014               [Page 42]