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]
