Internet DRAFT - draft-ietf-pkix-cmc-serverkeygeneration

draft-ietf-pkix-cmc-serverkeygeneration



 



PKIX WORKING GROUP                                             J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Intended Status: Proposed Standard                             S. Turner
Expires: July 5, 2012                                               IECA
                                                               P. Timmel
                                                National Security Agency
                                                         January 2, 2012

                 CMC Extensions: Server Key Generation 
             draft-ietf-pkix-cmc-serverkeygeneration-00.txt


Abstract

   This document defines a set of extensions to the Certificate
   Management over CMS (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."

   This Internet-Draft will expire on July 5, 2012.












 


Schaad, et al.            Expires July 5, 2012                  [Page 1]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


Copyright and License Notice

   Copyright (c) 2012 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  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.1  Shared Secret for Authentication and Key Protection . .  4
       1.1.2  Shared Secret for Authentication and Uncertified Key 
              for Protection  . . . . . . . . . . . . . . . . . . . .  5
       1.1.3. Certificate for Authentication and Uncertified or
              Certified Key for Protection  . . . . . . . . . . . . .  8
     1.2. Location of Key Generator . . . . . . . . . . . . . . . . .  9
       1.2.1. CA-generated keys . . . . . . . . . . . . . . . . . . .  9
       1.2.2. RA-generated keys . . . . . . . . . . . . . . . . . . . 10
     1.3  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 11
     1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 11
   2. Shrouding Algorithms  . . . . . . . . . . . . . . . . . . . . . 11
     2.1. Shroud With a Public Key  . . . . . . . . . . . . . . . . . 12
     2.2. Shroud With a Shared-Secret Key . . . . . . . . . . . . . . 14
   3. Enveloping Keys . . . . . . . . . . . . . . . . . . . . . . . . 15
   4. Server-Side Key Generation  . . . . . . . . . . . . . . . . . . 15
     4.1. Server-Side Key Generation Request Attribute  . . . . . . . 16
     4.2. Server-side Key Generation Response . . . . . . . . . . . . 17
   5. Additional Error Codes  . . . . . . . . . . . . . . . . . . . . 19
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 21
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 21
   Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 22
   Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 22
     B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 22
       B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 22
       B.1.2. Shroud with Public Key  . . . . . . . . . . . . . . . . 22
       B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 22
 


Schaad, et al.            Expires July 5, 2012                  [Page 2]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


     B.2. CA-Generate Key Response  . . . . . . . . . . . . . . . . . 22
     B.3. RA-Generate Key Response  . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22


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

   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.

   Sections 2 and 3 describe the concepts and structures used in
   transporting private keys between the server and client applications.
   Section 4 describes the structure and processes for server-side key
   generation.  Section 5 describes additional CMC error codes. 
   Appendix A provides the ASN.1 module for the CMC controls and errors.
    Appendix B provides example encodings.


1.1  Scenarios

   This section describes the three supported scenarios: where a shared
   secret is used to provide authentication and is used to encrypt the
   server-generated private key, where a shared secret is used for
   authentication and a bare, uncertified key is used for key
   protection, and where a certified key is used for authentication and
   a bare, uncertified key or certified key is used for protection.  The
   scenarios described in the following subsections assume that the key
 


Schaad, et al.            Expires July 5, 2012                  [Page 3]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   is generated at the Certificate Authority (CA), but key generation at
   Registration Authority (RA) is also supported (see Section 1.2). 
   Also, the scenarios assume that the transaction identifier and nonce
   controls are used for replay protection but they are optional in
   [RFC5272].


1.1.1  Shared Secret for Authentication and Key Protection

   When the client uses a shared secret to authenticate to the server
   and requests that the server protect the response with the same
   shared secret, Proof-of-Possession (POP) is not necessary.  POP is
   unnecessary in this case because the client does not need to prove to
   the server that it has possession of a private key because no client
   private key is used in the request or the response.  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 mechanism that is
   out-of-scope of this document.

   When the client generates their request, they include the following
   control attributes in a PKIData content type [RFC5272]:
   ServerKeyGenRequest (see Section 4.1), TransactionID [RFC5272],
   SenderNonce [RFC5272], and Identification [RFC5272].  The
   Identification control is only needed if the ServerKeyGenRequest's
   certificateRequest does not include a subject.  The PKIData is
   encapsulated in an AuthenticatedData content type and the password
   RecipientInfo (i.e., pwri CHOICE) is used [RFC5652].  Note that no
   reqSequence is 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 (optional)                   ||
     |+--------------------------------------------------------------+|
     +----------------------------------------------------------------+

   After the server authenticates the client, the server generates a
   response that includes the server-generated key and any associated
   parameters in an AsymmetricKeyPackage content type [RFC6030].  The
   AsymmetricKeyPackage 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 cmsSeq [RFC5272] and the following
 


Schaad, et al.            Expires July 5, 2012                  [Page 4]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   controls are included: TransactionID, SenderNonce, RecipientNonce
   [RFC5272], CMCStausInfoV2 [RFC5272], and ServerKeyGenResponse (see
   Section 4.2).  The PKIResponse is then encapsulated in a SignedData
   and the certificate associated with the server-generated key is
   placed in SignedData's certificate field [RFC5652].  The following
   depicts this:

     +---------------------------------------------------------+
     |SignedData: Signed by the CA                             |
     |             Certificate signed by the CA                |
     |+-------------------------------------------------------+|
     ||PKIResponse: control: TransactionID                    ||
     ||             control: SenderNonce                      ||
     ||             control: RecipientNonce                   ||
     ||             control: ServerKeyGenResponse             ||
     ||             control: CMCStatusInfoV2 (status: success)||
     ||                                                       ||
     ||             cmsSeq:                                   ||
     ||             +----------------------------------------+||
     ||             |EnvelopedData: RecipientInfo: pwri      |||
     ||             |+----------------------+                |||
     ||             ||SignedData            |                |||
     ||             ||+--------------------+|                |||
     ||             |||AsymmetricKeyPackage||                |||
     ||             ||+--------------------+|                |||
     ||             |+----------------------+                |||
     ||             +----------------------------------------+||
     |+-------------------------------------------------------+|
     +---------------------------------------------------------+

   The client can validate that the response came from the CA by
   validating the digital signature on the SignedData to a Trust Anchor
   (TA).  After the EnvelopedData is decrypted with the shared secret,
   the client can also verify that the private key is associated with
   the public key in the returned certificate and the client can also
   verify that the certificate validates back to a TA.


1.1.2  Shared Secret for Authentication and Uncertified Key for
   Protection

   When the client uses a shared secret to authenticate to the server
   and requests that the server protect the response with an uncertified
   public key, POP is necessary because the client would like the
   response encrypted with a public key and the server must determine
   that the client actually has the private key associated with the
   public key.  If the client requests that the response be encrypted
   with a key that also supports digital signatures, then the client can
 


Schaad, et al.            Expires July 5, 2012                  [Page 5]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   provide the POP in the same transaction as the server-side key
   generation request.  If the client requests that the response be
   encrypted with a key that does not support digital signatures, then
   additional round trips are necessary to perform POP exchanges with
   the encrypted/decrypted POP attributes [RFC5272].

   When the client's key supports both digital signatures and
   encryption, the client includes the following control attributes in a
   PKIData content type [RFC5272]: ServerKeyGenRequest control (see
   Section 4.1), TransactionID [RFC5272], SenderNonce [RFC5272],
   Identification [RFC5272], and POPLinkRandom [RFC5272].  The
   Identification control is only needed if the ServerKeyGenRequest's
   certificateRequest does not include a subject.  The POPLinkRandom and
   the ServerKeyGenRequest'd witness values, which includes
   POPLinkWitnessV2, are used to prove to the server that the client has
   possession of the private key.  The PKIData is encapsulated in an
   AuthenticatedData content type and the password RecipientInfo (i.e.,
   pwri CHOICE) is used [RFC5652].  Note that no reqSequence is included
   for the server-side key generation request.  The following depicts
   this:

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

   After the server has authenticated the client and verified the POP,
   the server returns the server-generated key and any associated
   parameters in an AsymmetricKeyPackage content type [RFC6030].  The
   AsymmetricKeyPackage is then encapsulated within a SignedData and
   that is encapsulated within an EnvelopedData using the key agreement
   or key transports RecipientInfo (i.e., kari or ketri CHOICE).  The
   EnvelopedData is then placed in a PKIResponse cmsSeq [RFC5272] and
   the following controls are included: TransactionID, SenderNonce,
   RecipientNonce, CMCStatusInfoV2, [RFC5272], and ServerKeyGenResponse
   (see Section 4.2).  The PKIResponse is then encapsulated in a
   SignedData and the certificate associated with the server-generated
   key is placed in SignedData's certificate field [RFC5652].  The
   following depicts this:



 


Schaad, et al.            Expires July 5, 2012                  [Page 6]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


     +-----------------------------------------------------------+
     |SignedData: Signed by the CA                               |
     |             Certificate signed by the CA                  |
     |+---------------------------------------------------------+|
     ||PKIResponse: control: TransactionID                      ||
     ||             control: SenderNonce                        ||
     ||             control: RecipientNonce                     ||
     ||             control: ServerKeyGenResponse               ||
     ||             control: CMCStatusInfoV2 (status: success)  ||
     ||                                                         ||
     ||             cmsSeq:                                     ||
     ||             +------------------------------------------+||
     ||             |EncryptedData: RecipientInfo: kari or keti|||
     ||             |+----------------------+                  |||
     ||             ||SignedData            |                  |||
     ||             ||+--------------------+|                  |||
     ||             |||AsymmetricKeyPackage||                  |||
     ||             ||+--------------------+|                  |||
     ||             |+----------------------+                  |||
     ||             +------------------------------------------+||
     |+---------------------------------------------------------+|
     +-----------------------------------------------------------+

   When client's key only supports encryption, the client includes the
   following in control attributes in a PKIData [RFC5272]: Server Key
   Generation Request control (see Section 4.1), TransactionID
   [RFC5272], SenderNonce [RFC5272], and Identification [RFC5272].  The
   Identification control is only needed if the certificateRequest does
   not include a subject.  The PKIData is encapsulated in an
   AuthenticatedData content type and the password RecipientInfo (i.e.,
   pwri CHOICE) is used [RFC5652].  Note that no reqSequence is included
   for the server-side key generation request.  The following depicts
   this:

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

   After the server has authenticated the client, the server must
   perform POP with the client.  This requires additional round trips
   for the client to prove that it can decrypt date encrypted for it by
   the server.  The server returns a PKIData with the following
 


Schaad, et al.            Expires July 5, 2012                  [Page 7]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   controls: TransactionID, SenderNonce, EncryptedPOP, and
   CMCStatusInfoV2.  The CMCStatusInfoV2 indicates that the request
   failed and why: POP required.  The EncryptedPOP control attribute
   contains some encrypted data for the client.  The PKIData is the
   encapsulated in a SignedData.  The following depicts this:

     +----------------------------------------------------------------+
     |SignedData: Signed by the CA                                    |
     |+--------------------------------------------------------------+|
     ||PKIData: control: TransationID                                ||
     ||         control: SenderNonce                                 ||
     ||         control: RecipientNonce                              ||
     ||         control: EncryptedPOP                                ||
     ||         control: CMCStatusInfoV2 (status: failed             ||
     ||                    OtherStatusInfo: CMCFailInfo: POPRequired)||
     |+--------------------------------------------------------------+|
     +----------------------------------------------------------------+

   After the client has validated the signature on the SignedData, it
   decrypts the EncryptedPOP with its private key and then generates a
   PKIData with the following controls: TransactionID, SenderNonce,
   RecipientNonce, and DecryptedPOP.  The decrypted data is placed in
   the DecryptedPOP control.  The PKIData is then encapsulated in an
   AuthenticatedData and then the client returns it to the server.  The
   following depicts this:

     +---------------------------------------+
     |AuthenticatedData: ReceipientInfo: pwri|
     |+--------------------------------+     |
     ||PKIData: control: TransationID  |     |
     ||         control: SenderNone    |     |
     ||         control: RecipientNonce|     |
     ||         control: DecryptedPOP  |     |
     |+--------------------------------+     |
     +---------------------------------------+

   After the client has authenticated the client and verified that the
   decrypted POP is correct, the server returns a response.  It is the
   same response as the one returned when the client's key supports
   digital signatures.


1.1.3. Certificate for Authentication and Uncertified or Certified Key
   for Protection

   When the client uses a certificate to authenticate to the server and
   requests that the server protect the response with a certificate or
   an uncertified public key or certificate, POP is still necessary
 


Schaad, et al.            Expires July 5, 2012                  [Page 8]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   because the client would like the response encrypted with a public
   key and the server must determine that the client actually has the
   private key associated with public key.  If the client requests that
   the response be encrypted with a key that also supports digital
   signatures, then the client can provide the POP in the same
   transaction as the server-side key generation request.  If the client
   requests that the response be encrypted with a key that does not
   support digital signatures, then additional round trips are necessary
   to perform encrypted/decrypted POP exchanges [RFC5272].  These
   additional round trips are necessary for the server to determine that
   the client posses the private key.

   The difference between this scenario and the one in Section 1.1.2 is
   that instead of an AuthenticatedData encapsulating the PKIData a
   SignedData is used. 


1.2. Location of Key Generator

   As noted earlier, these extensions are designed to not add additional
   round trips to the enrollment process.  This section depicts two
   scenarios: one when the Certification Authority (CA) generates keys
   and another when the Registration Authority (RA) generates the keys.

   In the figures below, CR is Certificate Request/Response and KGReq is
   Key Generation Request, and KGRes is Key Generation Response.  {}
   signifies encrypted.


1.2.1. CA-generated keys

   For CA-generated keys, the message flows is as follows:

     Client               RA             CA              Key Generator
           |              |              |              | 
           |------------->|------------->|              |
           | PKIData      |              |              |
           |  includes CR |              |              |
           |  and KGReq   |              |------------->|
           |              |              | KGReq        |
           |              |              |(out-of-scope)|
           |              |              |<-------------|
           |              |              |       KGRes  |
           |              |              |(out-of-scope)|
           |<-------------|<-------------|              
           |              |  PKIResponse |              
           |              |  includes CR |             
           |              |  and {KGRes} |              
 


Schaad, et al.            Expires July 5, 2012                  [Page 9]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   In this scenario, the CA authenticates the client's request and
   verifies the client's identity.  The CA generates the keys, issues
   the client's certificate, encrypts the key for the client, and signs
   the response.  As specified in [RFC5272], the RA is optional.  If an
   RA is involved, then the RA does not have access to encrypted portion
   of the response because it does not have access to either the shared
   secret or the client's private key. 


1.2.2. RA-generated keys

   For RA-generated keys, the message flow is as follows:

     Client               RA      Key Generator          CA 
           |              |              |              | 
           |------------->|              |              |
           | PKIData      |              |              |
           |  includes CR |              |              |
           |  and KGReq   |              |              |
           |              |------------->|              |
           |              | KGReq        |              |
           |              |(out-of-scope)|              |
           |              |<-------------|              |
           |              |        KGRes |              |
           |              |(out-of-scope)|              |
           |              |                             |
           |              |                             |
           |              |---------------------------->|
           |              | PKIData includes CR         |
           |              | and {KGRes} (optional)      |
           |              |<----------------------------|
           |              |     PKIResponse includes CR |
           |              |      and {KGRes} (optional) |
           |<-------------|                             |
           |  PKIResponse |                             |
           | includes CR  |                             |
           | and {KGRes}  |                             |


   NOTE: The encrypted KGRes could be provided to the CA for it to
   return to the client or the RA can retain the encrypted KGRes and
   return it as part of the PKIResponse it generates. In this scenario,
   the RA authenticates the client's request and verifies the client's
   identity.  The RA also verifies the POP verifies the encryption
   certificate (if used), generates the keys, and returns the encrypted
   private key.  The RA also sends the certificate request to the CA and
   assuming it performed POP includes an indication that it did so using
   the LRAPOPWitness control.  If the RA performed POP or based on local
 


Schaad, et al.            Expires July 5, 2012                 [Page 10]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   policy the RA encapsulates the client's request in a SignedData and
   places it in a PKIData content type for the CA.  The CA issues the
   client's certificate and signs the response.  In this scenario the RA
   does have access to the cleartext private key but the CA does not.


1.3  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] Section 2.1 applies to this profile.


1.4. Definitions

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

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

     o Pass phrase is a shared secret string between two or more
       entities that allows for a MAC or encryption key to be computed. 
       Pass phrases MUST be treated as confidential by the holders of
       the secret. 

     o Shrouding is used as 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.

2. Shrouding Algorithms

   For the server-side key generation control attribute described in
   this document to function, the client must be able to tell the server
   in advance what encryption algorithm and what key value is to be used
   for encrypting the private keys being returned.  In both of these
   cases, the encrypted data returned is returned as an EnvelopedData
   object as defined by [RFC5652] and placed in the cmsSequence field of
   a PKIResponse [RFC5272].  Client also must be able to tell the server
   in advance what digital signature and hash algorithms it supports to
   ensure the certificate request response and certificate can be
   verified.
 


Schaad, et al.            Expires July 5, 2012                 [Page 11]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   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 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-wrap algorithms and key derivation
   algorithms. The shroudMethod field defines the method by which the
   server will do the key management of the content encrypt 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 MUST include (a) the source of
   the key material, (b) the public or salting information, and (c) the
   method of deriving a key management key 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 key
   generation server and the end-entity.  This document does not define
   any such mechanism.

2.1. Shroud With a Public Key

   Clients can provide a public key to the server either wrapped in a
   certificate or as a bare public key.  For this shrouding algorithm,
   the public key provides the all of the information that is needed to
   allow for the returned key to be encrypted.  The following object
   identifier identifies the shroudWithPublicKey shroud method:

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






 


Schaad, et al.            Expires July 5, 2012                 [Page 12]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   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}
     }

     ShroudWithPublicKey ::= CHOICE {
       certificate  Certificate,
       bareKey       SEQUENCE {
         publicKey    SubjectPublicKeyInfo,
         ski          SubjectKeyIdentifier,
         witness      SEQUENCE {
           signature    Signature,
           sigAlg       SignatureAlgorithmIdentifier,
           value        CHOICE {
               link       POPLinkWitnessV2,
               certID     ESSCertIDV2
           }
         } OPTIONAL
       }
     }

   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.  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.  The server SHOULD perform a POP on
       the provided key prior to using it.

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

       - witness provides a method of doing POP using a signature
         algorithm.  This field is only present if the key is capable of
         doing signature operation.

 


Schaad, et al.            Expires July 5, 2012                 [Page 13]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


     o sigAlg contains the signature algorithm used to compute the
       signature value.

     o signature contains the signature value.

     o value contains the value that was signed.  The value MUST be DER
       encoded prior to performing the signature operation.

     o link is used when the outer wrapper is an AuthenticatedData
       structure.  If this is present then the POPLinkRandom MUST be
       present in the list of PKIData controls.  The link value is
       computed over the public key value using the shared secret as the
       MAC key.

     o certID is used when the outer wrapper is a SignedData structure. 
       It will identify the certificate that is used to sign the overall
       message.

   When this method is used with the certificate option, the server MUST
   validate the certificate back to a trust anchor.  Further, the server
   MUST check that the client provided certificate belongs to the same
   client that authenticated the certificate 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 MUST return a
   CMCFailInfo with the value of badCertificate, which is defined in
   Section 5.

   When this method is used with the publicKey option and the request is
   authenticated using a shared secret, the server MUST verify the
   POPLinkRandom/POPLinkWitnessV2, as specified in [RFC5272].  If this
   check fails, the server MUST return a CMCFailInfo with the value of
   popFailed [RFC5272].

   If the witness value is missing, the server MAY use the Encrypted and
   Decrypted POP controls [RFC5272] to perform the required POP
   operation.  Clients MUST support this if encryption-only keys are
   supported.


2.2. Shroud With a Shared-Secret Key

   Clients can indicate that servers use a shared secret value.  For
   this option the key material is identified by the identifier, the key
   derivation algorithms supported by the client are included in the
   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
 


Schaad, et al.            Expires July 5, 2012                 [Page 14]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   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 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 MUST check that the chosen
   shared secret belongs to the authenticated identity of the entity
   that generated the certificate request.  If this check fails, then
   the server MUST return a CMCFailInfo with the value of
   badSharedSecret, which is defined in Section 5.  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.


3. Enveloping Keys

   The server returns the private key and optionally the corresponding
   public key to the client with the AsymmetricKeyPackage content type
   [RFC5958].  The AsymmetricKeyPackage is encapsulated in a
   Cryptographic Message Syntax (CMS) EnvelopedData content type.  There
   MUST be only one OneAsymmetricKey present in the AsymmetricKeyPackage
   sequence.  When more than one private key is to be returned, multiple
   AsymmetricKeyPackages are included.  The public key SHOULD be
   included.


4. Server-Side Key Generation

   This section provides the control attributes necessary for doing
   server-side generation of keys for clients.  The client places the
 


Schaad, et al.            Expires July 5, 2012                 [Page 15]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   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.

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

     o shroudMethod contains the identifier of the 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.  Support 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
 


Schaad, et al.            Expires July 5, 2012                 [Page 16]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


       by the server when this is set to TRUE is out-of-scope.

   The client can request that the generated key be a specific algorithm
   by placing data in the publicKey field of the certificateRequest
   field.  If the publicKey field is populated, then the public key MUST
   be a zero length bit string.  If the client requests a specific
   algorithm, the server MUST generate a key of that algorithm (with the
   parameters if defined) or it MUST fail the request.  If the request
   fails for this reason, the server SHOULD return a CMCFailInfo with a
   value of badAlg [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 extension 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
   certificate request is denied due to the inability to handle a
   requested extension, the server MUST respond with a CMCFailInfo with
   a value of unsupportedExt [RFC5272].

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

   A server that does not support at least one of the algCapabilities
   MUST reject the request.  The server SHOULD return a CMCFailInfo with
   a value of badAlg [RFC5272].

   If archiveKey is true and the server that does not support archiving
   of private keys MUST reject the request.  The server SHOULD return a
   CMCFailInfo with a value of archiveNotSupported, defined in this
   document.


4.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:

 


Schaad, et al.            Expires July 5, 2012                 [Page 17]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


     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.  As per
   Section 3 of this document, the body MUST contain the version, the
   private key algorithm identifier, and the private key and the body
   SHOULD contain the public key and MAY contain additional attributes.

     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.

   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.







 


Schaad, et al.            Expires July 5, 2012                 [Page 18]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


5. 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)
     }

   If you think that you are going to want to return other information
   than just an error code then we can expand to a sequence of an
   integer and an any defined by integer or use a different extended
   error code just for those items. 

     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 }


6. Security Considerations

   Central generation of digital signature keys contains risks and is
   not always appropriate.  Organization-specific Certificate Policies
   should define whether or not server-side generation of digital
 


Schaad, et al.            Expires July 5, 2012                 [Page 19]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


   signature keys is permitted.

   Private keys must be appropriately protected from disclosure or
   modification on the 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.

   This specification requires implementations to generate key pairs and
   other random values.  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.

   POP is extremely important.  However, POP here is different than in
   client-generated key certification requests in that the POP is
   necessary to prove to the server that the client has possession of
   the private key necessary to decrypt the server-generated private key
   rather than possess the private key associated with the public key in
   the request.

   Further when the shared secret is used to provide client
   authentication and 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. Returning data to the wrong client
   is bad.  Disclosure of the private key to the wrong client can result
   in masquerades.


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


 


Schaad, et al.            Expires July 5, 2012                 [Page 20]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


8.  References

8.1  Normative References

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

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

   [RFC6030]  Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
              Key Container (PSKC)", RFC 6030, October 2010.


8.2  Informative References

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

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

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

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


 


Schaad, et al.            Expires July 5, 2012                 [Page 21]

INTERNET DRAFT   CMC Extensions: Server Key Generation   January 2, 2012


Appendix A. ASN.1 Module

   To be supplied later.

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

   Paul Timmel
   National Information Assurance Research Laboratory
   National Security Agency

   Email: pstimme@tycho.ncsc.mil  








Schaad, et al.            Expires July 5, 2012                 [Page 22]