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]