CMC Extensions: Server Side Key Generation and Key Escrow
draft-ietf-pkix-cmc-archive-01

Versions: 00 01                                                         
Network Working Group                                          J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Expires: August 5, 2005                                    February 2005


       CMC Extensions: Server Side Key Generation and Key Escrow
                   draft-ietf-pkix-cmc-archive-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 5, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a set of extensions to the CMC (Certificate
   Management over CMS) protocol that address the desire for having two
   additional services:  1) Server side generation of keys, 2)
   server-side escrow and subsequent recovery of key material.  These
   services are provided by the definition of additional control
   statements within the CMC architecture.




Schaad                   Expires August 5, 2005                 [Page 1]


Internet-Draft               CMC: Key Escrow               February 2005


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Requirements Terminology . . . . . . . . . . . . . . . . .  3
     1.2   Defintions . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Shroud With a Public Key . . . . . . . . . . . . . . . . .  5
     2.2   Shroud With a Shared-Secret Key  . . . . . . . . . . . . .  5
   3.  Enveloping a Private Key . . . . . . . . . . . . . . . . . . .  6
     3.1   Encrypted Private Key with Identifier  . . . . . . . . . .  6
     3.2   Multiple Encrypted Private Keys  . . . . . . . . . . . . .  7
   4.  Server-Side Key Generation . . . . . . . . . . . . . . . . . .  7
     4.1   Server-Side Key Generation Request Attribute . . . . . . .  7
     4.2   Server-side Key Generation Response  . . . . . . . . . . .  9
     4.3   Control Flow . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4   Recovery of pre-generated keys . . . . . . . . . . . . . . 10
     4.5   RA/LRA behavior modifications  . . . . . . . . . . . . . . 10
   5.  Key Archival and Recovery  . . . . . . . . . . . . . . . . . . 11
     5.1   Key Archival Control Attribute . . . . . . . . . . . . . . 11
       5.1.1   Using the Unsigned Attribute . . . . . . . . . . . . . 13
       5.1.2   Use the CMS Sequence . . . . . . . . . . . . . . . . . 13
     5.2   Key Recovery Request Control Attribute . . . . . . . . . . 13
       5.2.1   Key Recovery Response Control Attribute  . . . . . . . 14
     5.3   Control Flow . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Additional Error Codes . . . . . . . . . . . . . . . . . . . . 17
   7.  Interactions between Server side Key Gen and Archive
       Retrieval  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2  Informational References . . . . . . . . . . . . . . . . . 18
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
   A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 19
   B.  Sample Message Layouts . . . . . . . . . . . . . . . . . . . . 21
     B.1   Server Key Generation  . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 24














Schaad                   Expires August 5, 2005                 [Page 2]


Internet-Draft               CMC: Key Escrow               February 2005


1.  Overview

   This document defines a set of extensions to [CMC] (Certificate
   Management over CMS) that allow for 1) server side generation of key
   material, and 2) server side key archival and subsequent retrieval of
   the archived key material.  There are some strong reasons for
   providing each of these services.
   o  Clients can have poor key generation, and having multiple clients
      means that this must be checked for all clients.
   o  Hardware tokens may not have key generation capabilities.
   o  End users routinely lose keys from either user error or software
      errors.

   The creation of private keys relies on the use of good key generation
   algorithms.  In most cases this depends on the use of a superior
   random number generator and strong testing for such things a prime
   numbers.  The client side generation of this material can often times
   be suspect for either for reasons of poor coding in the multiple
   client applications, poor input (seeding material) from users and the
   requirements that user's not spend time waiting for things to occur.
   Moving the task of key generation to a server process allows for
   superior key generation as hardware can be installed in servers for
   the purpose of key generation.  There is a trade off for generation
   of signature keys on server systems.  It can provide for better key
   generation, but the ability for a server to know the signing key is
   an issue.  (Note:  In the case of DSS the parameter generation could
   be done on a server, while the private key is still generated on the
   client's system.  This allows for good parameter generation without
   sharing the private key with the server.)

   These extensions to the CMC protocol are designed to provide the
   services without adding any additional round trips to the enrollment
   process.  Server-side key generation is designed so that a
   client-side generated signature key and server-side generated
   key-management key can be processed in a single CMC interaction.

   Sections Section 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 the structure and process for doing
   key archival and retrieval.

1.1  Requirements Terminology

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





Schaad                   Expires August 5, 2005                 [Page 3]


Internet-Draft               CMC: Key Escrow               February 2005


1.2  Defintions

   This section defines some of the terms that we use in this document:
   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).
   Pass Phrase is a shared secret string between two or more entities
      that allows for a MAC to be computed.  This allows for a high
      degree of assurance that the data covered by the MAC actually came
      from one of the entities that knows the secret.  Pass phrases must
      be treated as confidential by the holders of the secret.
   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

   Both the server-side key generation and the key recovery control
   attributes described in this document require that the client be able
   to tell the server in advance what encryption algorithm and what key
   value is to be used in shrouding the private keys being returned.  In
   both of these cases the encrypted data returned is returned as an
   EnvelopedData object as defined by [CMS] and placed in the
   cmsSequence field of a ResponseBody.

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

   The encCapabilities field contains the advertised capabilities of the
   client-side entity.  This field use the S/MIME Capabilities type
   defined in section 2.5.2 of [MSG31].  The capabilities to be listed
   are 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 CEK value in an EnvelopedData.  The
   shroudMethod field uses the type ShroudMethod.  This type is defined
   as:

   ShroudMethod ::= AlgorithmIdentifier

   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; clients and servers MUST support id-cmc-shroudWithPublicKey.
   Clients and servers SHOULD support id-cmc-shroudWithSharedSecret.



Schaad                   Expires August 5, 2005                 [Page 4]


Internet-Draft               CMC: Key Escrow               February 2005


2.1  Shroud With a Public Key

   Clients can provide a public key to the server either as a bare key
   or wrapped in a certificate.

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

      ShroudWithPublicKey ::= CHOICE {
                certificate     Certificate,
                publicKey               SubjectPublicKey
      }

   certificate provides a public key certificate containing the key to
      be used.  Servers SHOULD check that the subject and subject
      alternative names match in some way with the entity that the
      private key is destined for.
   publicKey provides a bare public key that is to be used for
      encrypting the content encryption key.  When a bare public key is
      encountered serves need to perform some type of authentication
      before returning an encrypted private key.

   Servers and clients MUST support use of RSA keys for key management.
   Servers and clients MAY support use of DH keys for key management.

2.2  Shroud With a Shared-Secret Key

   A shared secret value is identified to the server by the client.  The
   derived key is then used as a key encryption key in the EnvelopedData
   recipient info structure.  This shrouding method is identified by
   id-cmc-shroudWithSharedSecret.  The parameter type associated with
   this shrouding method is ShroudWithSharedSecret.  The ASN.1 for these
   items follows:

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

      ShroudWithSharedSecret ::= UTF8String


   The common identification string for the client and the server is
   placed in the UTF8String field.  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 encCapabilities
   field.  The identification string is used to identify the pass phrase
   or shared key

   Clients and servers MUST support the PBKDF2 key derivation algorithm
   defined in [CMS-ALGS].




Schaad                   Expires August 5, 2005                 [Page 5]


Internet-Draft               CMC: Key Escrow               February 2005


   If shared-secret shrouding is supported, clients and servers MUST
   support the AES key wrap algorithm as defined by [AES-WRAP].  Clients
   and servers SHOULD support 3DES key wrap.  Clients and servers MAY
   support RC2 key-wrap.  The latter two algorithms are defined in
   [CMS-ALGS].

3.  Enveloping a Private Key

   Two different methods of enveloping a private key are supported.
   Both are defined by different content types for the EnvelopedData
   type from [CMS].  The first is used both for sending private keys
   from a client to a server and returning it from a server to a client.
   The second is used for returning multiple keys from a server to a
   client.  The assumption is made that a client rarely sends multiple
   keys to a server for escrow at the same time and thus can deal with
   the additional overhead from having multiple EnvelopedData objects in
   the request message.

   The definition of how to place private keys into the PrivateKeyInfo
   structure can be found in section X of [CRMF].

   [[[[QUESTION: There are three different ways of attacking this
   problem.  The group needs to discuss and agree on a common method.
   These methods are:
   1.  Use the Multiple Encrypted Private keys defined in this document.
   2.  State that if you are returning multiple keys, then you just have
       to deal with multiple returned EnvelopedData items.  Only real
       issue is size and this case needs to be dealt with in any event.
       In some cases the escrow agent is merely a storage agent and
       keeps the encrypted blob rather than decrypting and storing the
       private key along with identification.
   3.  Extend the CRMF type to allow for multiple keys.  This would
       allow for sending multiple keys to the server in a simpler
       manner, but still requires that option 2 of multiple items be
       allowed.  Currently no backwards compatibility issues until this
       update of CRMF passes last call.

   ]]]]

3.1  Encrypted Private Key with Identifier

   The encrypted private key with identifier content type is defined in
   [CRMF].  When using this type, the identifier MUST be present when
   sending private keys from the client to the server.  This allows for
   an additional check by the server that the private keys are being
   escrowed by the owner of the keys.  If one can create this message
   with a correct identifier in it, then one has possession of the
   private key blob.



Schaad                   Expires August 5, 2005                 [Page 6]


Internet-Draft               CMC: Key Escrow               February 2005


3.2  Multiple Encrypted Private Keys

   The multiple encrypted private keys is used when multiple private
   keys are to be from a single escrow agent for a single client.  The
   OID defined for this content type and the body are as follows:

   id-ct-multiplePrivateKey OBJECT IDENTIFIER ::= {id-ct XX}

   MultiplePrivateKey ::= SEQUENCE OF ExtendedPrivateKey

   ExtendedPrivateKey ::= SEQUENCE {
       privateKey         PrivateKeyInfo,
       certificateId        RecipientIdentifier
   }


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

   Clients SHOULD NOT request server-side generation of signing-only key
   pairs.  Servers SHOULD NOT grant requests for generation of key-pairs
   and creating a signing only certificate.  This is designed to reduce
   responsibility on the server's part for possible use of the signing
   keys.

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 has the
   following OID and structure:

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

   ServerKeyGenRequest ::= SEQUENCE {
        certificateRequest              CertTemplate,
        shroudMethod              ShroudMethod,
        encCapabilities         SMimeCapabilties,
        fArchiveKey                     BOOLEAN DEFAULT FALSE,



Schaad                   Expires August 5, 2005                 [Page 7]


Internet-Draft               CMC: Key Escrow               February 2005


        selectionCriteria               OCTET STRING OPTIONAL
   }

   certificateRequest contains the data fields that the client suggests
      for the certificate being requested for the server generated key
      pair.
   shroudMethod contains the identifier of the algorithm to be used in
      deriving the key used to encrypt the private key.
   encCapabilities 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.
   fArchiveKey is set to TRUE if the client wishes the key to be
      archived as well as generated on the server.  Servers MAY archive
      the server-generated key even if fArchiveKey is set to FALSE.
      Servers SHOULD NOT generate the key pair when archival is
      requested but the server would not archive the key material.
   selectionCriteria contains a string allowing for the selective
      retrieval of archived keys from the server.  The selectionCriteria
      field should appear only if fArchiveKey is set to TRUE.

   The client can request that the generated key be a specific algorithm
   by placing data in the publicKey field of the certificateRequest
   field.  When the publicKey field is populated, the subjectPublicKey
   MUST be a zero length bit string and the algorithmIdentifier SHOULD
   omit the parameters field.  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.  Servers MUST
   support key generation for RSA.  Servers MAY support key generation
   for Diffie-Hellman.  Servers MAY support key generation for other
   algorithms.

   If the request contains no requested algorithm, servers SHOULD
   generate an RSA key exchange key pair.

   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 [PKIXCERT].  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 signing.)  If a certificate
   request is denied due to the inability to handle a requested
   extension, the server MUST respond with a failInfo attribute of
   unsupportedExt.




Schaad                   Expires August 5, 2005                 [Page 8]


Internet-Draft               CMC: Key Escrow               February 2005


   The identity proof algorithm presented in section 5.2 in [CMC] does
   not work if there are no certificate requests present.  If the
   request contains no certificate request objects and the request is
   not being signed by a pre-existing signing certificate, the algorithm
   in section 5.2 should be modified to use the set of server key
   generation requests encoded in a sequence as the data hashed.

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 originating 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 recovery response control
   attribute has the following OID and syntax:

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

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

   cmsBodyPartId identifies a TaggedContentInfo contained within the
      enclosing PKIData.  The ContentInfo object is of type
      EnvelopedData and has a body of id-ct-encKeyWithID.  The body MUST
      contain the private key and MAY contain an identifier.
   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.
   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).  The server MAY additionally return CRLs in
   the CRL bag.  Servers MAY include the self-signed certificates.
   Clients MUST NOT implicitly trust included self-signed certificate(s)
   merely due to its presence in the certificate bag.  In the event
   clients receive a new self-signed certificate from the server,
   clients SHOULD provide a mechanism to enable the user to explicitly
   trust the certificate.



Schaad                   Expires August 5, 2005                 [Page 9]


Internet-Draft               CMC: Key Escrow               February 2005


4.3  Control Flow

   In the following control flow examples, Èó‚é¼ÊôclientÈó‚é¼Ã¥ refers to the
   entity requesting generation of a private key, and Èó‚é¼ÊôserverÈó‚é¼Ã¥
   refers to the key generation facility.
   1.  The client creates a CMC message containing a server-side key
       generation request.  The required information is filled in on the
       request.
   2.  Optionally, any client-side key generation is done (for signing
       keys) and the certificate requests are constructed and placed in
       the PKIData request message.
   3.  If the client possesses a signing key, or one was created in step
       2, it is used to sign the CMC message.  If no signing key exists,
       the PKIData request body is placed in an AuthenticatedData
       structure and a shared secret is used to authenticate the
       message.
   4.  The request is sent to the server.
   5.  The server does the key generation for the request.
   6.  The server issues all required certificates.
   7.  The server creates a CMC response message with the following
       attributes:
       A.  All certificates requested are placed in the certificateList
           in the CMS SignedData object
       B.  The private key generated is encoded as a id-ct-encKeyWithID
           ContentInfo object.
       C.  The ContentInfo object is wrapped in a CMS EnvelopedData
           object using the shrouding information from the request.
       D.  The EnvelopedData object is placed in the cmcSequence of a
           PKI-Responses Body.
       E.  An id-cmc-serverKeyGetnResponse control is placed in the CMS
           SignedData object pointing to the EnvelopedData object.
   8.  The CMC response message sent to client.

4.4  Recovery of pre-generated keys

   Some server-side key generation servers will need to limit the number
   of current certified key-pairs for clients.  Under these
   circumstances a server MAY return an already existing certified
   key-pair if the keys and certificate satisfy the server-side key
   generation request.

4.5  RA/LRA behavior modifications

   In many cases the actual processing of key archival and key
   generation controls is done not at the Certification Authority, but
   at a Registration agent.  This section discusses the differences in
   the protocol based on an RA doing the key generation.




Schaad                   Expires August 5, 2005                [Page 10]


Internet-Draft               CMC: Key Escrow               February 2005


   An LRA that does the key generation operation would behave as follows
   1.  The key generation would be done in response to the request as
       above.
   2.  A certificate request body is placed in a new CMC message along
       with the clients CMC message.  (Optionally a new CMC message
       containing all requests plus all relevant controls could be
       constructed.)
   3.  The new CMC message is then sent to the Certification Authority.
   4.  When the response is returned, the LRA builds a new CMC response
       message containing the encrypted private key info and all
       relevant certificates.

   If the AuthenticatedData object is used to provide for protection of
   the data between the client and the RA, two different shared secrets
   may be needed to provide the originators identity (one for the RA and
   one for the CA).  However, one would generally work on the assumption
   in this case that the RA/LRA would be allowed to assert that both POP
   and identity have been proved.

5.  Key Archival and Recovery

   Servers MAY require key archival of encryption keys as a condition of
   issuing a certificate for that encryption key pair.  Servers MAY
   reject all requests contained within a PKIData if any required key
   archival message is missing for any element within the PKIData.

   There are four objects involved in key archival and recovery
   scenarios:
   1.  The Key Archival control attribute,
   2.  The Key Recovery Request control attribute,
   3.  The Key Recovery Response control attribute,
   4.  A ContentInfo containing private key material.

   It is assumed that a key recovery operation will only return
   previously archived material.  (That is, if an archival operation and
   a recovery operation happen simultaneously, the newly archived key
   material is not returned as part of the recovery response.)

5.1  Key Archival Control Attribute

   This control is used to indication that key archival is to take
   place.  The actual data to be archived an live in one of two
   different locations.  The first is in an EnvelopedData object in the
   cmsSequence of the request message.  The second is as part of the
   id-aa-cmc-unsignedData attribute in the SignedData section of the
   request message.  The two different methods of sending the data allow
   for different constraints to be dealt with.




Schaad                   Expires August 5, 2005                [Page 11]


Internet-Draft               CMC: Key Escrow               February 2005


   The data is placed in the body in those cases where one is either
   dealing only with an archive agent, or where it is of extreme
   importance to make sure that the EnvelopedData body has not been
   tampered with in any way.

   The data is placed in the unsigned attribute in those cases where it
   needs to be removed in the middle of processing by the escrow agent.
   A common case where this occurs is when the escrow agent is inside of
   a company (or division in the company) and the actual certificate
   authority is outside of the company (or division).  By removing the
   data from the enrollment message, the outside authority has no chance
   to attempt and decrypt it.

   All systems MUST support placing the EnvelopedData object in the
   unsigned attribute.  All escrow agents SHOULD support having the
   EnvelopedData object inside of the body.  All keys are returned
   inside of a body in either event.

   The key archival control attribute has the following ASN.1 syntax:

   id-cmc-keyArchival OBJECT IDENTIIFER ::= { id-cmc XX}

   KeyArchival ::= SEQUENCE {
       keyIdentification   CHOICE {
          reqBodyPartID       BodyPartID,
          certificateID       RecipientIdentifier
       }
       cmsBodyPartID        BodyPartID,
       selectionCriteria    OCTET STRING OPTIONAL
   }

   reqBodyPartID is a reference to the payload within the enclosing
      PKIData that contains the certification request for the public key
      component of the encryption key pair.  If multiple certification
      requests for the same public key are included in the PKIData,
      reqBodyPartID may point to any one of them.
   certificateID is a reference to a certificate that contains the
      public key for the private key being escrowed.  This element is
      used if the key is being archived at a different point in time
      than a certificate is being  requested for the key.
   cmsBodyPartID notifies the escrow agent where the EnvelopedData
      object containing the private key is to be found.  If the value is
      non-zero is a reference to an EnvelopedData object in the
      cmsSequence section of the same body.  If the value is zero, then
      the EnvelopedData is found in the unsignedAttributes of a
      SignedData object.  Only one id-cmc-keyArchive control can exist
      in a body where the value is zero.  (I.e.  only one key can be
      archived using this method.)



Schaad                   Expires August 5, 2005                [Page 12]


Internet-Draft               CMC: Key Escrow               February 2005


   selectionCriteria is optional information to be associated with the
      archived key material to facilitate key recovery of subsections of
      the archive database.

   The EnvelopedData object referred to MUST have an encapsulated
   content type of id-ct-encKeyWithID.  The identifier field MUST be
   populated if the EnvelopedData object has been encrypted for any
   entity other than the originator to decrypt.

   Some escrow agents will archive the entire EnvelopedData without
   examining it for correctness.  In these cases the private key will be
   shrouded to a private secret of the client only.

   Escrowing a key with an escrow agent is one way that is permitted for
   POP verification to be done.  In this case the escrow agent would add
   a wrapping layer with the id-cmc-lraPOPWitness control pointing to
   the certificate request matching the archived private key.

5.1.1  Using the Unsigned Attribute

   When the EnvelopedData object is placed in the unsigned attribute
   section of a SignedData object, it is done as follows:
   1.  The EnvelopedData object is constructed.
   2.  A unsigned attribute id-aa-cmc-unsignedData is created where:
       A.  the field bodyPartPath consists of the body part id for the
           id-cmc-archiveRequest control,
       B.  the field identifier is set to id-cmc-archive-enveloped-data,
       C.  the content is set to the EnvelopedData object.
   3.  The unsigned attribute is placed in the outermost SignedData
       object created.  If there is more than one SignerInfo block
       (extremely unusual), then it must be the same in all SignerInfo
       blocks.

   Note that when the processing is done by the escrow agent, the
   unsigned attribute will have migrated outwards gaining fields in the
   bodyPartPath as the layers of wrapping are added.  This allows for
   the attribute to be matched to the correct request body.

5.1.2  Use the CMS Sequence

   If the EnvelopedData field is to be embedded in the message, then a
   tag is created and it is placed in the cmsSequence section of the
   request body.

5.2  Key Recovery Request Control Attribute

   The key recovery request control attribute has the following ASN.1
   syntax:



Schaad                   Expires August 5, 2005                [Page 13]


Internet-Draft               CMC: Key Escrow               February 2005


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

   KeyRecoveryReq ::= SEQUENCE {
        shroudMethod              ShroudMethod,
        encCapabilities         SMimeCapabilities,
        selectionCriteria               OCTET STRING OPTIONAL
   }


   shroudMethod structure defines the encryption method and key material
      that MUST be used in the key recovery response to encrypt the
      recovered private key material.
   encCapabilities provides a set of algorithm identifiers that
      identifies the capabilities of the client.  The server MUST use
      algorithms that are identified by this list.
   selectionCriteria is optional information to be associated with the
      archived key material to facilitate key recovery of subsections of
      the archive database.  If selectionCriteria is absent, all
      archived keys associated with the enrolling identity MUST be
      returned.  [the selectionCriteria sounds rather detailed given the
      abstract quality of the rest of this discussion.  Why not just
      present the public key(s) in question?]

   Notice that the recovery request does not include any end-entity
   identification.  Determination of the identity comes from other
   locations: The name in a certificate request, the name in an identity
   proof, the name in the shrouding certificate or the name in the
   signing certificate on the containing SignedInfo structure.  Servers
   need to establish a policy to be used by that server for identifying
   the entity doing the request operation.

5.2.1  Key Recovery Response Control Attribute

   The key recovery response control attribute has the following ASN.1
   syntax:

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

   KeyRecoveryRsp ::= SEQUENCE {
        cmsBodyPartID           BodyPartID,
        certificateID       RecipientIdentifier OPTIONAL,
        selectionCriteria       OCTET STRING OPTIONAL
   }








Schaad                   Expires August 5, 2005                [Page 14]


Internet-Draft               CMC: Key Escrow               February 2005


   cmsBodyPartID identifies a TaggedContentInfo contained within the
      enclosing PKIData.  The object referenced is to be an
      EnvelopedData object with an embedded content type of either
      id-encKeyWithID or id-multipleKey.  The shouding in the associated
      recovery request is used in constructing the EnvelopedData object.
   certificateID provides an association with the certificate and the
      recovered key.  This field is used only if a the
      id-ct-encKeyWithID content info type is used in the associated
      EnvelopedData object.  If the id-ct-multipleKeys content info type
      is used, then the associations are placed in that object rather
      than here.
   selectionCriteria is the optional information that was used to
      retrieve a subset of the keys archived in the archive database.
      [see corresponding comment above]

5.3  Control Flow

   In the following control flow examples, Èó‚é¼ÊôclientÈó‚é¼Ã¥ refers to the
   entity archiving a private key or requesting recovery of a private
   key, and Èó‚é¼ÊôserverÈó‚é¼Ã¥ refers to the key archive facility.

   Control flow for Key Archival is assumed to proceed as follows:
   1.  Client retrieves an encryption certificate for the archiving
       server, so that key material to be archived may be encrypted to
       it.
   2.  Client generates an encryption key pair.
   3.  Client submits an enrollment request for the key pair.  As part
       of the PKIData, the client includes:
       A.  A certificate request (PKCS10 or CRMF) for the key pair,
           which includes the public key component and a message
           identifier (either bodyPartID or certReqId),
       B.  A Key Archival control attribute, which includes two message
           identifier references:
           1.  The identifier of the certification request in (3a), and
           2.  The identifier of the ContentInfo in (3c).
       C.  A ContentInfo containing inside it the private key material
           corresponding to the public key contained in the request in
           (3a) and encrypted using the public key from the certificate
           obtained in (1).
   4.  Server receives the request, archives the key material, and
       issues certificates as appropriate.  Server responds with an
       enrollment response containing the issued certificates.
   5.  It is assumed that whatever mechanisms are used to identify the
       entity requesting certification also serve to identify the
       archiving party.

   Control flow for Key Recovery is assumed to proceed as follows:




Schaad                   Expires August 5, 2005                [Page 15]


Internet-Draft               CMC: Key Escrow               February 2005


   1.  Client sends a Full PKI Request message containing the Key
       Recovery Request control attribute to the server.  (The PKIData
       need contain only the Key Recovery Request attribute.)
   2.  Server performs policy-based operations to determine whether the
       recovery request is valid.
   3.  Assuming the request is indeed valid, the server sends back to
       the client a Full PKI Response containing:
       A.  One or more Key Recovery Response control attributes.
       B.  One or more Private Key attributes containing encrypted
           private key material as defined in section 0 above.
   4.  Client processes the response and extracts private key material
       from the ContentInfo(s).

   The above control flow for key recovery assumes that the client
   possesses at least a previously-certified signature key, which is
   used to sign the Full PKI Request message.  In the event of a
   catastrophic failure on the client resulting in loss of all client
   keys, generation and certification of a new signature key may occur
   simultaneously to a request for recovery of private encryption keys.
   Control flow for recovering from catastrophic failure may proceed as
   follows:
   1.  Client generates a new signature key pair and creates a
       certification request for the public component of the new
       signature key.
   2.  Client creates a Full PKI Request message containing:
       A.  The certificate request from Step 1,
       B.  A Key Recovery Request control attribute.
   3.  The Full PKI Request message is signed using the private
       signature key generated as part of Step 1.  Following Section
       4.2, the signerInfo field of the signed message will contain a
       NULL issuer name and a serial number corresponding to the
       bodyPartID of the certificate request within the PKIData.  Notice
       that as it is not possible for the client to prove identity
       within the PKI (because all certified key pairs have been lost),
       another form of proof-of-identity is required (such as use of the
       identification and identityProof control attributes).
   4.  Client sends the Full PKI Request to the server.
   5.  Server performs policy-based operations on the request message to
       determine:
       1.  Whether the certification request on the new signature key
           should be granted, and
       2.  Whether the recovery request is valid.
   6.  Assuming that both requests are valid, the server sends back to
       the client a Full PKI Response containing:
       1.  A certificate for the signature key, corresponding to the
           certification request generated by the client.
       2.  One or more Key Recovery Response control attributes.




Schaad                   Expires August 5, 2005                [Page 16]


Internet-Draft               CMC: Key Escrow               February 2005


       3.  One or more Private Key attributes containing private key
           material as defined in section 3.4.8.4.
   7.  Client processes the response and extracts private key material
       and certificates.

6.  Additional Error Codes

   CMC Archival servers MUST use the id-cmc-statusInfoExt for all
   failures specific to this document.  The ExtendedFailInfo section of
   OtherInfo is used to convey the more detailed information used here.
   For generic failures, such as bad signatures on the SignedData
   object, the failure codes from [CMC] are used.

   The error codes defined in this document are identified by the object
   identifier id-cmc-errs-archive.

   The following error codes are defined by this document:
      the specified shroud method in the request is either unknown to or
      unsupported by the server.

7.  Interactions between Server side Key Gen and Archive Retrieval

   There are no interactions between the two.  If a key gen uses an
   existing key to satisfy the key gen request, that key MUST be omitted
   from a key recovery request in the same CMC message.  It MUST be
   included if the recovery request comes in a separate message.

8.  Open Issues
      What if there were no keys to be recovered in response to a
      recovery response?
      How about a first request of a key with no existing info.  Can't
      sign the wrapper.  Èó‚鼂ǣ Use AuthenticatedData object from CMS?
      Open question dealing with returning multiple keys in section  ?.?

9.  Security Considerations

   - Servers should never generate signing key material.

   - POP and identity proofs are important.

   - Protection of key material on user's machine, in transit and on
   server's machine.

   - Issues with using MACs for identification

   - Good random number generation

   - Returning data to the wrong people



Schaad                   Expires August 5, 2005                [Page 17]


Internet-Draft               CMC: Key Escrow               February 2005


10.  References

10.1  Normative References

   [AES-WRAP]
              Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [CMC]      Schaad, J., "Certificate Management over CMS", Work In
              Progress , February 2005.

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

   [CMS-ALGS]
              Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [CRMF]     Schaad, J., "Internet X.509 Certificate Request Message
              Format", Work In Progress , February 2005.

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

   [MSG31]    Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions(S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

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

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

10.2  Informational References

   [DH]     Kaliski, B., "PKCS 3: Diffie-Hellman Key Agreement v1.4",
            Lost 1900.

   [PKCS1]  Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5",
            PKCS #1, March 1998.

   [PKCS8]  RSA Laboratories, "PKCS#8: Private-Key Informaiton Syntax",
            PKCS #8, November 1993.




Schaad                   Expires August 5, 2005                [Page 18]


Internet-Draft               CMC: Key Escrow               February 2005


Author's Address

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

   Phone: 425-785-1031
   Email: jimsch@exmsft.com

Appendix A.  ASN.1 Module

   CMC-ARCHIVE

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
   -- PXIX CRMF                 FROM [CRMF]
      CertTemplate
      FROM PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1)
              security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}

   -- PKIX CMC                  FROM [CMC-BASE]
      BodyPartID, id-cmc
      FROM EnrollmentMessageSyntax { iso(1) identified-organization(3)
              dod(4) internet(1) security(5) mechansims(5) pkix(7)
              id-mod(0) id-mod-cmc(6)}

   -- S/MIME CMS                FROM [CMS]
      IssuerAndSerialNumber
      FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
              rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
   -- S/MIME Message             FROM [MSG31]
      SMimeCapabilities
      FROM SecureMimeMessageV3dot1 {iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
              msg-v3dot1(21) }

   -- PKIX Part 1 Èó‚鼂ǣ Implicit          FROM [PROFILE]
      AlgorithmIdentifier, Attribute, Certificate, SubjectPublicKeyInfo
      FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-pkix1-implicit(18)};


     -- Shroud Methods are used to identify the algorithm and



Schaad                   Expires August 5, 2005                [Page 19]


Internet-Draft               CMC: Key Escrow               February 2005


     -- structures used in shrouding data returned.

     ShroudMethod ::= AlgorithmIdentifier

     -- Data to be returned is encrypted and the content encryption
     -- key is encrypted by this public key.

     id-cmc-shroudWithPublicKey OBJECT IDENTIFIER ::= {id-cmc XX0}
     ShroudWithPublicKey ::= CHOICE {
         certificate     Certificate,
         publicKey       SubjectPublicKeyInfo
     }

     -- Data to be returned is encrypted and the content encryption
     -- key  is encrypted by a key derived from the associated pass phrase

     id-cmc-shroudWithSharedSecret OBJECT IDENTIFIER ::= {id-cmc XX1}
     ShroudWithSharedSecret ::= UTF8String


     -- CMS ContentInfo type for holding multiple keys
     --
     -- This type allows for return of multiple private keys along
     -- with and identifier to associate each private key with a
     -- certificate.

     id-ct-multiplePrivateKeys OBJECT IDENTIFIER ::= {id-ct XX}
     MultiplePrivateKeys ::= SEQUENCE OF SinglePrivateKey

     SinglePrivateKey ::= SEQUENCE {
       privateKey     PrivateKeyInfo,
       certificateId  RecipientIdentifier
     }

     -- This CMC control is used to request server side key generation
     -- to occur.

     id-cmc-ServerKeyGenRequest OBJECT IDENTIFIER ::= {id-cmc XX4}
     ServerKeyGenRequest ::= SEQUENCE {
        certificateRequest       CertTemplate,
        shroudMethod             ShroudMethod,
        encCapabilities          SMimeCapabilities,
        fArchiveKey              BOOLEAN DEFAULT FALSE,
        selectionCriteria        OCTET STRING OPTIONAL
     }

     -- This CMC control is used to return the results of a server side
     -- key generation operation.  The actual key is placed in the



Schaad                   Expires August 5, 2005                [Page 20]


Internet-Draft               CMC: Key Escrow               February 2005


     -- an EnvelopedData object in the cmsSequence portion of the response

     id-cmc-ServerKeyGenResponse OBJECT IDENTIFIER ::= {id-cmc XX5}
     ServerKeyGenResponse ::= SEQUENCE {
        cmsBodyPartId            BodyPartID,
        requestBodyPartId        BodyPartID,
        issuerAndSerialNumber    IssuerAndSerialNumber OPTIONAL
     }

     -- This CMC control is used to archive a private key with
     -- an escrow server.

     id-cmc-KeyArchival OBJECT IDENTIFIER ::= {id-cmc XX6}
     KeyArchival ::= SEQUENCE {
        keyIdentification        CHOICE {
           reqBodyPartID            BodyPartID,
           certificateID            RecipientIdentifier
        }
        cmsBodyPartID            BodyPartID,
        selectionCriteria        OCTET STRING OPTIONAL
     }

      id-cmc-keyRecoveryReq OBJECT IDENTIFIER ::= {id-cmc XX7}
      KeyRecoverReq ::= SEQUENCE {
         shroudMethod             ShroudMethod,
         encCapabilities          SMimeCapabilities,
         selectionCriteria        OCTET STRING OPTIONAL
      }

      id-cmc-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-cmc XX8}
      KeyRecoveryRsp ::= SEQUENCE {
         cmsBodyPartID            BodyPartID,
         certificateId            RecipientIdentifier,
         selectionCriteria        OCTET STRING OPTIONAL
      }

   END


Appendix B.  Sample Message Layouts

   This appendix contains several sample message sequences.  Note that
   these are not complete messages but trimmed down messages giving only
   the content where needed.

Appendix B.1  Server Key Generation

   In this example, both a signing-only certificate and an



Schaad                   Expires August 5, 2005                [Page 21]


Internet-Draft               CMC: Key Escrow               February 2005


   encryption-only certificate are being requested.  The client supplies
   the key for the signing-only certificate and the server supplies the
   key for the encryption-only certificate.

   Message from client to server:

   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-identityProof, computed value},
           {103, id-cmc-senderNonce, 10001}
           {104, id-cmc-serverkeyGenRequest, {
             {subject = cn="my identity string"},
             {id-cmc-shroudWithSharedSecret, identity string},
             {{id-PBKDF2}, {id-aes128-wrap}, {id-aes128-CBC}}}
         reqSequence
           certRequest
             certReqID=201
               certTemplate
                 subject = "cn=my identity string"
                 publicKey = My Public Signing key
                 extentions
                   {id-ce-subjectPublicKeyIdentifer, 100001}
                   {id-ce-keyUsage, digitalSignature}
       SignedData.SignerInfos
         SignerInfo
           sid.subjectKeyIdentifier = 100001

   Response from server to client:



















Schaad                   Expires August 5, 2005                [Page 22]


Internet-Draft               CMC: Key Escrow               February 2005


   ContentInfo.contentType = id-SignedData
     ContentInfo.content
       SignedData.encapContentInfo
         eContentType = id-ct-PKIResponse
         eContent
           controlSequence
             {102, id-cmc-cMCStatusInfoEx, {success, {201, 104}}}
             {103, id-cmc-senderNonce, 10005}
             {104, id-cmc-recipientNonce, 10001}
             {105, id-cmc-serverKeyGenResponse, 201, 104,
               {CA issuer name, enc cert serial number}}
           cmsSequence
             {201,
               {id-EnvelopedData,
                  recipientInfo[1].pwri
                    version = 1
                    keyDerivationAlgorithm = id-PBKDF2
                    keyEncryptionAlgortihm = id-aes-128wrap
                  EncryptedContentInfo
                    contentType = id-ct-encKeyWithID
                    contentEncryptionAlgorithm = id-aes128-cbc
                    encryptedContent
                       privateKey = private key structure}}
       certificates
         Newly issued signing certificate
         Newly issued encryption certificate
         Other certificates
       SignedData.SignerInfos
         Signed by CA






















Schaad                   Expires August 5, 2005                [Page 23]


Internet-Draft               CMC: Key Escrow               February 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Schaad                   Expires August 5, 2005                [Page 24]