Internet DRAFT - draft-ietf-pkix-cmc-serverkeygeneration
draft-ietf-pkix-cmc-serverkeygeneration
PKIX WORKING GROUP J. Schaad
Internet-Draft Soaring Hawk Consulting
Intended Status: Proposed Standard S. Turner
Expires: July 5, 2012 IECA
P. Timmel
National Security Agency
January 2, 2012
CMC Extensions: Server Key Generation
draft-ietf-pkix-cmc-serverkeygeneration-00.txt
Abstract
This document defines a set of extensions to the Certificate
Management over CMS (CMC) protocol that addresses the desire to
support server-side generation of keys. This service is provided by
the definition of additional control statements within the CMC
architecture. Additional CMC errors are also defined.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 5, 2012.
Schaad, et al. Expires July 5, 2012 [Page 1]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Shared Secret for Authentication and Key Protection . . 4
1.1.2 Shared Secret for Authentication and Uncertified Key
for Protection . . . . . . . . . . . . . . . . . . . . 5
1.1.3. Certificate for Authentication and Uncertified or
Certified Key for Protection . . . . . . . . . . . . . 8
1.2. Location of Key Generator . . . . . . . . . . . . . . . . . 9
1.2.1. CA-generated keys . . . . . . . . . . . . . . . . . . . 9
1.2.2. RA-generated keys . . . . . . . . . . . . . . . . . . . 10
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Shrouding Algorithms . . . . . . . . . . . . . . . . . . . . . 11
2.1. Shroud With a Public Key . . . . . . . . . . . . . . . . . 12
2.2. Shroud With a Shared-Secret Key . . . . . . . . . . . . . . 14
3. Enveloping Keys . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Server-Side Key Generation . . . . . . . . . . . . . . . . . . 15
4.1. Server-Side Key Generation Request Attribute . . . . . . . 16
4.2. Server-side Key Generation Response . . . . . . . . . . . . 17
5. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1 Normative References . . . . . . . . . . . . . . . . . . . 21
8.2 Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 22
B.1. Client Requests . . . . . . . . . . . . . . . . . . . . . . 22
B.1.1. Shroud with Certificate . . . . . . . . . . . . . . . . 22
B.1.2. Shroud with Public Key . . . . . . . . . . . . . . . . 22
B.1.3. Shroud with Shared Secret . . . . . . . . . . . . . . . 22
Schaad, et al. Expires July 5, 2012 [Page 2]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
B.2. CA-Generate Key Response . . . . . . . . . . . . . . . . . 22
B.3. RA-Generate Key Response . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1 Introduction
This document defines a set of extensions to and errors for
Certificate Management over Cryptographic Message Syntax (CMC)
[RFC5272] that allows for server-side generation of key material.
There are strong reasons for providing this service:
o Clients may have poor, unknown, or non-existent key generation
capabilities. The creation of private keys relies on the use of
good key generation algorithms and a robust random number
generator. Server key generation can use specialized hardware
that may not always be available on clients.
o Central storage of keys may be desired in some environments to
permit key recovery. This document only addresses a request to
archive server-generated keys; archival of locally generated keys
and the control to retrieve archived keys is out-of-scope.
o Server key generation may be useful for provisioning keys to
disconnected devices.
These extensions to the CMC protocol are designed to provide server
key generation without adding any additional round trips to the
enrollment process; however, additional round trips may be required
based on the mechanism chosen to protect the returned key.
Sections 2 and 3 describe the concepts and structures used in
transporting private keys between the server and client applications.
Section 4 describes the structure and processes for server-side key
generation. Section 5 describes additional CMC error codes.
Appendix A provides the ASN.1 module for the CMC controls and errors.
Appendix B provides example encodings.
1.1 Scenarios
This section describes the three supported scenarios: where a shared
secret is used to provide authentication and is used to encrypt the
server-generated private key, where a shared secret is used for
authentication and a bare, uncertified key is used for key
protection, and where a certified key is used for authentication and
a bare, uncertified key or certified key is used for protection. The
scenarios described in the following subsections assume that the key
Schaad, et al. Expires July 5, 2012 [Page 3]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
is generated at the Certificate Authority (CA), but key generation at
Registration Authority (RA) is also supported (see Section 1.2).
Also, the scenarios assume that the transaction identifier and nonce
controls are used for replay protection but they are optional in
[RFC5272].
1.1.1 Shared Secret for Authentication and Key Protection
When the client uses a shared secret to authenticate to the server
and requests that the server protect the response with the same
shared secret, Proof-of-Possession (POP) is not necessary. POP is
unnecessary in this case because the client does not need to prove to
the server that it has possession of a private key because no client
private key is used in the request or the response. The shared
secret allows the server to authenticate the client and allows the
server to encrypt the server-side generated key for the client. The
shared secret is distributed via an out-of-band mechanism that is
out-of-scope of this document.
When the client generates their request, they include the following
control attributes in a PKIData content type [RFC5272]:
ServerKeyGenRequest (see Section 4.1), TransactionID [RFC5272],
SenderNonce [RFC5272], and Identification [RFC5272]. The
Identification control is only needed if the ServerKeyGenRequest's
certificateRequest does not include a subject. The PKIData is
encapsulated in an AuthenticatedData content type and the password
RecipientInfo (i.e., pwri CHOICE) is used [RFC5652]. Note that no
reqSequence is included in the PKIData for the server-side key
generation request. The following depicts this:
+----------------------------------------------------------------+
|AuthenticatedData: ReceipientInfo: pwri |
|+--------------------------------------------------------------||
||PKIData: control: ServerKeyGenRequest (ShroudWithSharedSecret)||
|| control: TransationID ||
|| control: SenderNonce ||
|| control: Identification (optional) ||
|+--------------------------------------------------------------+|
+----------------------------------------------------------------+
After the server authenticates the client, the server generates a
response that includes the server-generated key and any associated
parameters in an AsymmetricKeyPackage content type [RFC6030]. The
AsymmetricKeyPackage is then encapsulated within a SignedData and
that is further encapsulated within an EnvelopedData using the
password RecipientInfo (i.e., pwri CHOICE). The EnvelopedData is
then placed in a PKIResponse cmsSeq [RFC5272] and the following
Schaad, et al. Expires July 5, 2012 [Page 4]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
controls are included: TransactionID, SenderNonce, RecipientNonce
[RFC5272], CMCStausInfoV2 [RFC5272], and ServerKeyGenResponse (see
Section 4.2). The PKIResponse is then encapsulated in a SignedData
and the certificate associated with the server-generated key is
placed in SignedData's certificate field [RFC5652]. The following
depicts this:
+---------------------------------------------------------+
|SignedData: Signed by the CA |
| Certificate signed by the CA |
|+-------------------------------------------------------+|
||PKIResponse: control: TransactionID ||
|| control: SenderNonce ||
|| control: RecipientNonce ||
|| control: ServerKeyGenResponse ||
|| control: CMCStatusInfoV2 (status: success)||
|| ||
|| cmsSeq: ||
|| +----------------------------------------+||
|| |EnvelopedData: RecipientInfo: pwri |||
|| |+----------------------+ |||
|| ||SignedData | |||
|| ||+--------------------+| |||
|| |||AsymmetricKeyPackage|| |||
|| ||+--------------------+| |||
|| |+----------------------+ |||
|| +----------------------------------------+||
|+-------------------------------------------------------+|
+---------------------------------------------------------+
The client can validate that the response came from the CA by
validating the digital signature on the SignedData to a Trust Anchor
(TA). After the EnvelopedData is decrypted with the shared secret,
the client can also verify that the private key is associated with
the public key in the returned certificate and the client can also
verify that the certificate validates back to a TA.
1.1.2 Shared Secret for Authentication and Uncertified Key for
Protection
When the client uses a shared secret to authenticate to the server
and requests that the server protect the response with an uncertified
public key, POP is necessary because the client would like the
response encrypted with a public key and the server must determine
that the client actually has the private key associated with the
public key. If the client requests that the response be encrypted
with a key that also supports digital signatures, then the client can
Schaad, et al. Expires July 5, 2012 [Page 5]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
provide the POP in the same transaction as the server-side key
generation request. If the client requests that the response be
encrypted with a key that does not support digital signatures, then
additional round trips are necessary to perform POP exchanges with
the encrypted/decrypted POP attributes [RFC5272].
When the client's key supports both digital signatures and
encryption, the client includes the following control attributes in a
PKIData content type [RFC5272]: ServerKeyGenRequest control (see
Section 4.1), TransactionID [RFC5272], SenderNonce [RFC5272],
Identification [RFC5272], and POPLinkRandom [RFC5272]. The
Identification control is only needed if the ServerKeyGenRequest's
certificateRequest does not include a subject. The POPLinkRandom and
the ServerKeyGenRequest'd witness values, which includes
POPLinkWitnessV2, are used to prove to the server that the client has
possession of the private key. The PKIData is encapsulated in an
AuthenticatedData content type and the password RecipientInfo (i.e.,
pwri CHOICE) is used [RFC5652]. Note that no reqSequence is included
for the server-side key generation request. The following depicts
this:
+-------------------------------------------------------------+
|AuthenticatedData: ReceipientInfo: pwri |
|+-----------------------------------------------------------+|
||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)||
|| control: TransationID ||
|| control: SenderNonce ||
|| control: Identification (optional) ||
|| control: POPLinkRandom ||
|+-----------------------------------------------------------+|
+-------------------------------------------------------------+
After the server has authenticated the client and verified the POP,
the server returns the server-generated key and any associated
parameters in an AsymmetricKeyPackage content type [RFC6030]. The
AsymmetricKeyPackage is then encapsulated within a SignedData and
that is encapsulated within an EnvelopedData using the key agreement
or key transports RecipientInfo (i.e., kari or ketri CHOICE). The
EnvelopedData is then placed in a PKIResponse cmsSeq [RFC5272] and
the following controls are included: TransactionID, SenderNonce,
RecipientNonce, CMCStatusInfoV2, [RFC5272], and ServerKeyGenResponse
(see Section 4.2). The PKIResponse is then encapsulated in a
SignedData and the certificate associated with the server-generated
key is placed in SignedData's certificate field [RFC5652]. The
following depicts this:
Schaad, et al. Expires July 5, 2012 [Page 6]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
+-----------------------------------------------------------+
|SignedData: Signed by the CA |
| Certificate signed by the CA |
|+---------------------------------------------------------+|
||PKIResponse: control: TransactionID ||
|| control: SenderNonce ||
|| control: RecipientNonce ||
|| control: ServerKeyGenResponse ||
|| control: CMCStatusInfoV2 (status: success) ||
|| ||
|| cmsSeq: ||
|| +------------------------------------------+||
|| |EncryptedData: RecipientInfo: kari or keti|||
|| |+----------------------+ |||
|| ||SignedData | |||
|| ||+--------------------+| |||
|| |||AsymmetricKeyPackage|| |||
|| ||+--------------------+| |||
|| |+----------------------+ |||
|| +------------------------------------------+||
|+---------------------------------------------------------+|
+-----------------------------------------------------------+
When client's key only supports encryption, the client includes the
following in control attributes in a PKIData [RFC5272]: Server Key
Generation Request control (see Section 4.1), TransactionID
[RFC5272], SenderNonce [RFC5272], and Identification [RFC5272]. The
Identification control is only needed if the certificateRequest does
not include a subject. The PKIData is encapsulated in an
AuthenticatedData content type and the password RecipientInfo (i.e.,
pwri CHOICE) is used [RFC5652]. Note that no reqSequence is included
for the server-side key generation request. The following depicts
this:
+-------------------------------------------------------------+
|AuthenticatedData: ReceipientInfo: pwri |
|+-----------------------------------------------------------+|
||PKIData: control: ServerKeyGenRequest (ShroudWithPublicKey)||
|| control: TransationID ||
|| control: SenderNonce ||
|| control: Identification (optional) ||
|+-----------------------------------------------------------+|
+-------------------------------------------------------------+
After the server has authenticated the client, the server must
perform POP with the client. This requires additional round trips
for the client to prove that it can decrypt date encrypted for it by
the server. The server returns a PKIData with the following
Schaad, et al. Expires July 5, 2012 [Page 7]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
controls: TransactionID, SenderNonce, EncryptedPOP, and
CMCStatusInfoV2. The CMCStatusInfoV2 indicates that the request
failed and why: POP required. The EncryptedPOP control attribute
contains some encrypted data for the client. The PKIData is the
encapsulated in a SignedData. The following depicts this:
+----------------------------------------------------------------+
|SignedData: Signed by the CA |
|+--------------------------------------------------------------+|
||PKIData: control: TransationID ||
|| control: SenderNonce ||
|| control: RecipientNonce ||
|| control: EncryptedPOP ||
|| control: CMCStatusInfoV2 (status: failed ||
|| OtherStatusInfo: CMCFailInfo: POPRequired)||
|+--------------------------------------------------------------+|
+----------------------------------------------------------------+
After the client has validated the signature on the SignedData, it
decrypts the EncryptedPOP with its private key and then generates a
PKIData with the following controls: TransactionID, SenderNonce,
RecipientNonce, and DecryptedPOP. The decrypted data is placed in
the DecryptedPOP control. The PKIData is then encapsulated in an
AuthenticatedData and then the client returns it to the server. The
following depicts this:
+---------------------------------------+
|AuthenticatedData: ReceipientInfo: pwri|
|+--------------------------------+ |
||PKIData: control: TransationID | |
|| control: SenderNone | |
|| control: RecipientNonce| |
|| control: DecryptedPOP | |
|+--------------------------------+ |
+---------------------------------------+
After the client has authenticated the client and verified that the
decrypted POP is correct, the server returns a response. It is the
same response as the one returned when the client's key supports
digital signatures.
1.1.3. Certificate for Authentication and Uncertified or Certified Key
for Protection
When the client uses a certificate to authenticate to the server and
requests that the server protect the response with a certificate or
an uncertified public key or certificate, POP is still necessary
Schaad, et al. Expires July 5, 2012 [Page 8]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
because the client would like the response encrypted with a public
key and the server must determine that the client actually has the
private key associated with public key. If the client requests that
the response be encrypted with a key that also supports digital
signatures, then the client can provide the POP in the same
transaction as the server-side key generation request. If the client
requests that the response be encrypted with a key that does not
support digital signatures, then additional round trips are necessary
to perform encrypted/decrypted POP exchanges [RFC5272]. These
additional round trips are necessary for the server to determine that
the client posses the private key.
The difference between this scenario and the one in Section 1.1.2 is
that instead of an AuthenticatedData encapsulating the PKIData a
SignedData is used.
1.2. Location of Key Generator
As noted earlier, these extensions are designed to not add additional
round trips to the enrollment process. This section depicts two
scenarios: one when the Certification Authority (CA) generates keys
and another when the Registration Authority (RA) generates the keys.
In the figures below, CR is Certificate Request/Response and KGReq is
Key Generation Request, and KGRes is Key Generation Response. {}
signifies encrypted.
1.2.1. CA-generated keys
For CA-generated keys, the message flows is as follows:
Client RA CA Key Generator
| | | |
|------------->|------------->| |
| PKIData | | |
| includes CR | | |
| and KGReq | |------------->|
| | | KGReq |
| | |(out-of-scope)|
| | |<-------------|
| | | KGRes |
| | |(out-of-scope)|
|<-------------|<-------------|
| | PKIResponse |
| | includes CR |
| | and {KGRes} |
Schaad, et al. Expires July 5, 2012 [Page 9]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
In this scenario, the CA authenticates the client's request and
verifies the client's identity. The CA generates the keys, issues
the client's certificate, encrypts the key for the client, and signs
the response. As specified in [RFC5272], the RA is optional. If an
RA is involved, then the RA does not have access to encrypted portion
of the response because it does not have access to either the shared
secret or the client's private key.
1.2.2. RA-generated keys
For RA-generated keys, the message flow is as follows:
Client RA Key Generator CA
| | | |
|------------->| | |
| PKIData | | |
| includes CR | | |
| and KGReq | | |
| |------------->| |
| | KGReq | |
| |(out-of-scope)| |
| |<-------------| |
| | KGRes | |
| |(out-of-scope)| |
| | |
| | |
| |---------------------------->|
| | PKIData includes CR |
| | and {KGRes} (optional) |
| |<----------------------------|
| | PKIResponse includes CR |
| | and {KGRes} (optional) |
|<-------------| |
| PKIResponse | |
| includes CR | |
| and {KGRes} | |
NOTE: The encrypted KGRes could be provided to the CA for it to
return to the client or the RA can retain the encrypted KGRes and
return it as part of the PKIResponse it generates. In this scenario,
the RA authenticates the client's request and verifies the client's
identity. The RA also verifies the POP verifies the encryption
certificate (if used), generates the keys, and returns the encrypted
private key. The RA also sends the certificate request to the CA and
assuming it performed POP includes an indication that it did so using
the LRAPOPWitness control. If the RA performed POP or based on local
Schaad, et al. Expires July 5, 2012 [Page 10]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
policy the RA encapsulates the client's request in a SignedData and
places it in a PKIData content type for the CA. The CA issues the
client's certificate and signs the response. In this scenario the RA
does have access to the cleartext private key but the CA does not.
1.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
The terminology in [RFC5272] Section 2.1 applies to this profile.
1.4. Definitions
This section defines some of the terms that are used in this
document:
o Identification is used as a generic term for a name, generally
assigned by a server, used to match a request against a known
individual. Identification can be either authenticated (a
subject name in a certificate) or unauthenticated (a text
string).
o Pass phrase is a shared secret string between two or more
entities that allows for a MAC or encryption key to be computed.
Pass phrases MUST be treated as confidential by the holders of
the secret.
o Shrouding is used as a generic term to cover methods of masking
the content of an object from unauthorized viewers. The most
common method of shrouding used is encryption of the data.
2. Shrouding Algorithms
For the server-side key generation control attribute described in
this document to function, the client must be able to tell the server
in advance what encryption algorithm and what key value is to be used
for encrypting the private keys being returned. In both of these
cases, the encrypted data returned is returned as an EnvelopedData
object as defined by [RFC5652] and placed in the cmsSequence field of
a PKIResponse [RFC5272]. Client also must be able to tell the server
in advance what digital signature and hash algorithms it supports to
ensure the certificate request response and certificate can be
verified.
Schaad, et al. Expires July 5, 2012 [Page 11]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
Each request control for which the response includes encrypted data
contains two fields to define type of encryption used:
algCapabilities and shroudMethod.
The algCapabilities field contains the advertised capabilities of the
client-side entity. This field uses the S/MIME Capabilities type
defined in section 2.5.2 of [RFC5751]. The capabilities to be listed
are digital signature algorithms, message digest algorithms, content
encryption algorithms, key-wrap algorithms and key derivation
algorithms. The shroudMethod field defines the method by which the
server will do the key management of the content encrypt key (CEK)
value in EnvelopedData. The shroudMethod field uses the type
ShroudMethod. This type is defined as:
ShroudMethod ::= AlgorithmIdentifier
{ SHROUD-ALGORITHM, { ShroudAlgorithmSet } }
When a new shroud method is defined it MUST include (a) the source of
the key material, (b) the public or salting information, and (c) the
method of deriving a key management key using the requested data,
source key material and salt. This document defines two shroud
methods: id-cmc-shroudWithPublicKey and id-cmc-
shroudWithSharedSecret. Clients and servers MUST support id-cmc-
shroudWithPublicKey. Client and servers SHOULD support id-cmc-
shroudWithSharedSecret.
Other shrouding methods could be defined in the future that would not
involve the use of EnvelopedData. For example, one could conceive of
a shrouding method that required the use of Transport Layer Security
(TLS) [RFC5246] to provide the necessary security between the key
generation server and the end-entity. This document does not define
any such mechanism.
2.1. Shroud With a Public Key
Clients can provide a public key to the server either wrapped in a
certificate or as a bare public key. For this shrouding algorithm,
the public key provides the all of the information that is needed to
allow for the returned key to be encrypted. The following object
identifier identifies the shroudWithPublicKey shroud method:
id-cmc-shroudWithPublicKey OBJECT IDENTIFER ::= {id-cmc XX }
Schaad, et al. Expires July 5, 2012 [Page 12]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
shroudWithPublicKey has the ASN.1 type ShroudWithPublicKey:
srda-shroudWithPublicKey SHROUD-ALGORITHM ::= {
IDENTIFIED BY id-cmc-shroudWithPublicKey,
PARAMS TYPE ShroudWithPublicKey ARE required,
SMIME-CAPS {IDENTIFIED BY id-cmc-shroudWithPublicKey}
}
ShroudWithPublicKey ::= CHOICE {
certificate Certificate,
bareKey SEQUENCE {
publicKey SubjectPublicKeyInfo,
ski SubjectKeyIdentifier,
witness SEQUENCE {
signature Signature,
sigAlg SignatureAlgorithmIdentifier,
value CHOICE {
link POPLinkWitnessV2,
certID ESSCertIDV2
}
} OPTIONAL
}
}
The fields of type ShroudWithPublicKey have the following meanings:
o certificate provides a public key certificate containing the
public key to be used for encrypting the server-generated private
key from the server to the client. Servers SHOULD check that the
subject and subject alternative names match in some way with the
entity that the private key is destined for.
o bareKey allows for an arbitrary public key to be used to return
the encrypted private key. The server SHOULD perform a POP on
the provided key prior to using it.
- publicKey contains the public key that is to be used for
encrypting the private key returned from the server to the
client.
- ski contains the SubjectKeyIdentifier that will be used in CMS
EnvelopedData to identify the public key when encrypting the
private key from the server to the client.
- witness provides a method of doing POP using a signature
algorithm. This field is only present if the key is capable of
doing signature operation.
Schaad, et al. Expires July 5, 2012 [Page 13]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
o sigAlg contains the signature algorithm used to compute the
signature value.
o signature contains the signature value.
o value contains the value that was signed. The value MUST be DER
encoded prior to performing the signature operation.
o link is used when the outer wrapper is an AuthenticatedData
structure. If this is present then the POPLinkRandom MUST be
present in the list of PKIData controls. The link value is
computed over the public key value using the shared secret as the
MAC key.
o certID is used when the outer wrapper is a SignedData structure.
It will identify the certificate that is used to sign the overall
message.
When this method is used with the certificate option, the server MUST
validate the certificate back to a trust anchor. Further, the server
MUST check that the client provided certificate belongs to the same
client that authenticated the certificate request (e.g. the
certificate subjects match, or the client provided certificate
belongs to the same entity as the authentication shared secret). If
either of these checks fails, then the server MUST return a
CMCFailInfo with the value of badCertificate, which is defined in
Section 5.
When this method is used with the publicKey option and the request is
authenticated using a shared secret, the server MUST verify the
POPLinkRandom/POPLinkWitnessV2, as specified in [RFC5272]. If this
check fails, the server MUST return a CMCFailInfo with the value of
popFailed [RFC5272].
If the witness value is missing, the server MAY use the Encrypted and
Decrypted POP controls [RFC5272] to perform the required POP
operation. Clients MUST support this if encryption-only keys are
supported.
2.2. Shroud With a Shared-Secret Key
Clients can indicate that servers use a shared secret value. For
this option the key material is identified by the identifier, the key
derivation algorithms supported by the client are included in the
algCapabilities field. No salting material is provided by the
client. The derived key is then used as a key encryption key in the
EnvelopedData recipient info structure. The following object
Schaad, et al. Expires July 5, 2012 [Page 14]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
identifier identifies the shroudWithSharedSecret control attribute:
id-cmc-shroudWithSharedSecret OBJECT IDENTIFER ::= {id-cmc XX}
shroudWithSharedSecret attribute values have the ASN.1 type
ShroudWithSharedSecret:
shrda-shroudWithSharedSecret SHROUD-ALGORITHM ::= {
IDENTIFIED BY id-cmc-shroudWithSharedSecret
PARAMS TYPE ShroudWithSharedSecret ARE required
SMIME-CAPS {IDENTIFIED BY id-cmc-shroudWithSharedSecret}
ShroudWithSharedSecret ::= UTF8String
The common identification string for the client and the server is
placed in the ShroudWithSharedSecret field, which a UTFString
[RFC5280]. In addition the client needs to place both a key
derivation function and a key wrap function in the set of
capabilities advertised by the client in the algCapabilities field.
The identification string is used to identify the pass phrase or
shared key.
When this method is used, the server MUST check that the chosen
shared secret belongs to the authenticated identity of the entity
that generated the certificate request. If this check fails, then
the server MUST return a CMCFailInfo with the value of
badSharedSecret, which is defined in Section 5. In general, while it
is expected that the same identity token and shared secret used to do
the identity authentication are used to derive the key encryption key
this is not required.
3. Enveloping Keys
The server returns the private key and optionally the corresponding
public key to the client with the AsymmetricKeyPackage content type
[RFC5958]. The AsymmetricKeyPackage is encapsulated in a
Cryptographic Message Syntax (CMS) EnvelopedData content type. There
MUST be only one OneAsymmetricKey present in the AsymmetricKeyPackage
sequence. When more than one private key is to be returned, multiple
AsymmetricKeyPackages are included. The public key SHOULD be
included.
4. Server-Side Key Generation
This section provides the control attributes necessary for doing
server-side generation of keys for clients. The client places the
Schaad, et al. Expires July 5, 2012 [Page 15]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
request for the key generation in a request message and sends it to
the server. The server will generate the key pair, create a
certificate for the public key and return the data in a response
message, or the server will return a failure.
4.1. Server-Side Key Generation Request Attribute
The client initiates a request for server-side key generation by
including the server-side key generation request attribute in the
control attributes section of a PKIData object. The request
attribute includes information about how to return the generated key
as well as any client suggested items for the certificate. The
control attribute for doing server-side key generation is identified
by the following OID:
id-cmc-serverKeyGenRequest OBJECT IDENTIFIER ::= { id-cmc XX }
The Server-Side Key Generation Request control attribute has the
following ASN.1 definition:
cmc-serverKeyGenRequest CMC-CONTROL ::= {
ServerKeyGenRequest IDENTIFIED BY id-cmc-serverKeyGenRequest }
ServerKeyGenRequest ::= SEQUENCE {
certificateRequest CertTemplate,
shroudMethod ShroudMethod,
algCapabilities SMimeCapabilties OPTIONAL,
archiveKey BOOLEAN DEFAULT TRUE
}
The fields in ServerKeyGenRequest have the following meaning:
o certificateRequest contains the data fields that the client
suggests for the certificate being requested for the server
generated key pair.
o shroudMethod contains the identifier of the algorithm to be used
in deriving the key used to encrypt the private key.
o algCapabilities contains the set of algorithm capabilities being
advertised by the client. The server uses algorithms from this
set in the ServerKeyGenResponse object to encrypt the private key
of the server-generated key pair. Support is OPTIONAL because
this information might be carried in a signed attribute, included
within a certificate or be part of the local configuration.
o archiveKey is set to TRUE if the client wishes the key to be
archived as well as generated on the server. Further processing
Schaad, et al. Expires July 5, 2012 [Page 16]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
by the server when this is set to TRUE is out-of-scope.
The client can request that the generated key be a specific algorithm
by placing data in the publicKey field of the certificateRequest
field. If the publicKey field is populated, then the public key MUST
be a zero length bit string. If the client requests a specific
algorithm, the server MUST generate a key of that algorithm (with the
parameters if defined) or it MUST fail the request. If the request
fails for this reason, the server SHOULD return a CMCFailInfo with a
value of badAlg [RFC5272].
A server is not required to use all of the values suggested by the
client in the certificate template. Servers MUST be able to process
all extensions defined in [RFC5280]. Servers are not required to be
able to process other V3 X.509 extension transmitted using this
protocol, nor are they required to be able to process other, private
extensions. Servers are permitted to modify client-requested
extensions. Servers MUST NOT alter an extension so as to invalidate
the original intent of a client-requested extension. (For example
change key usage from key exchange to digital signature.) If a
certificate request is denied due to the inability to handle a
requested extension, the server MUST respond with a CMCFailInfo with
a value of unsupportedExt [RFC5272].
A server that does not recognize the algorithm identified in
shroudMethod MUST reject the request. The server SHOULD return a
CMCFailInfo with a value of badAlg [RFC5272].
A server that does not support at least one of the algCapabilities
MUST reject the request. The server SHOULD return a CMCFailInfo with
a value of badAlg [RFC5272].
If archiveKey is true and the server that does not support archiving
of private keys MUST reject the request. The server SHOULD return a
CMCFailInfo with a value of archiveNotSupported, defined in this
document.
4.2. Server-side Key Generation Response
The server creates a server-side key generation response attribute
for every key generation request made and successfully completed.
The response message has a pointer to both the original request
attribute and to the body part in the current message that holds the
encrypted private keys. The response message also can contain a
pointer to the certificate issued. The key generation response
control attribute is identified by the OID:
Schaad, et al. Expires July 5, 2012 [Page 17]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
id-cmc-serverKeyGenResponse OBJECT IDENTIFIER ::= {id-cmc XX}
The Server-Side Key Generation Response control attribute has the
following ASN.1 definition:
cmc-serverKeyGenResponse CMC-CONTROL ::= {
ServerKeyGenResponse IDENTIFIED BY id-cmc-serverKeyGenResponse }
ServerKeyGenResponse ::= SEQUENCE {
cmsBodyPartId BodyPartID,
requestBodyPartId BodyPartID,
issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL
}
The fields in ServerKeyGenResponse have the following meaning: o
cmsBodyPartId identifies a TaggedContentInfo contained within the
enclosing PKIData. The ContentInfo object is of type EnvelopedData
and has an encapsulated content of id-ct-KP-aKeyPackage. As per
Section 3 of this document, the body MUST contain the version, the
private key algorithm identifier, and the private key and the body
SHOULD contain the public key and MAY contain additional attributes.
o requestBodyPartId contains the body part identifier for the
server-side key generation request control attribute. This
allows for clients to associate the resulting key and certificate
with the original request.
o issuerAndSerialNumber if present contains the identity of the
certificate issued to satisfy the request. The certificate is
placed in the certificate bag of the immediately encapsulating
signedData object.
Clients MUST NOT assume the certificates are in any order. Servers
SHOULD include all intermediate certificates needed to form complete
chains to one or more self-signed certificates, not just the newly
issued certificate(s) in the certificate bag. The server MAY
additionally return CRLs in the CRL bag. Servers MAY include self-
signed certificates. Clients MUST NOT implicitly trust included
self-signed certificate(s) merely due to its presence in the
certificate bag.
Schaad, et al. Expires July 5, 2012 [Page 18]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
5. Additional Error Codes
This section defines ExtendedFailInfo errors from this document:
cmc-err-keyGeneration EXTENDED-FAILURE-INFO ::= {
TYPE ErrorList IDENTIFIED BY id-tbd
}
ErrorList ::= INTEGER {
archiveNotSupported (1),
badCertificate (2),
badSharedSecret (3)
}
If you think that you are going to want to return other information
than just an error code then we can expand to a sequence of an
integer and an any defined by integer or use a different extended
error code just for those items.
o archiveNotSupported indicates that the server does not support
archiving of private keys. The syntax for the ExtendedFailInfo
is as follows:
cmc-err-archiveNotSupport EXTENDED-FAILURE-INFO ::={
IDENTIFIED BY id-tbd }
o badCertificate indicates that the certificate to be used to
encrypt the response did not validate back to a RA/CA trust
anchor or the certificate does not belong to the client. The
syntax for the ExtendedFailInfo is as follows:
cmc-err-badCertificate EXTENDED-FAILURE-INFO ::={
IDENTIFIED BY id-tbd }
o badSharedSecret indicates that the shared secret provided by the
client does not match that stored by the server.
cmc-err-badSharedSecret EXTENDED-FAILURE-INFO ::={
IDENTIFIED BY id-tbd }
6. Security Considerations
Central generation of digital signature keys contains risks and is
not always appropriate. Organization-specific Certificate Policies
should define whether or not server-side generation of digital
Schaad, et al. Expires July 5, 2012 [Page 19]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
signature keys is permitted.
Private keys must be appropriately protected from disclosure or
modification on the server, in transit, and on the client.
Cryptographic algorithms and keys used to protect the private key
should be at least as strong as the private key's intended strength.
This specification requires implementations to generate key pairs and
other random values. The use of inadequate pseudo-random number
generators (PRNGs) can result in little or no security. The
generation of quality random numbers is difficult. NIST Special
Publication 800-90 [SP-800-90] and FIPS 186 [FIPS-186] offer
guidance.
POP is extremely important. However, POP here is different than in
client-generated key certification requests in that the POP is
necessary to prove to the server that the client has possession of
the private key necessary to decrypt the server-generated private key
rather than possess the private key associated with the public key in
the request.
Further when the shared secret is used to provide client
authentication and protect the server-generated private key, the
shared secret must be kept secret for the lifetime of the key. This
is because disclosure could allow attackers to determine the server-
generated private key. This is different than certification requests
with client-generated keys because the shared secret is no longer
needed after the authentication. Returning data to the wrong client
is bad. Disclosure of the private key to the wrong client can result
in masquerades.
7. IANA Considerations
This document makes use of object identifiers to register CMC control
attributes and CMC error codes. Additionally, an object identifier
is used to identify the ASN.1 module found in Appendix A. All are
defined in an arc delegated by IANA to the PKIX Working Group. The
current contents of the arc are located here:
http://www.imc.org/ietf-pkix/pkix-oid.asn
They were obtained by sending a request to ietf-pkix-oid-reg@imc.org.
When the PKIX WG closes, this arc and registration procedures will
be transferred to IANA. No further action by IANA is necessary for
this document or any anticipated updates.
Schaad, et al. Expires July 5, 2012 [Page 20]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August
2010.
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
Key Container (PSKC)", RFC 6030, October 2010.
8.2 Informative References
[FIPS-186] National Institute of Standards and Technology (NIST),
FIPS 186-3 DRAFT: Digital Signature Standard (DSS),
November 2008.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SP-800-90] National Institute of Standards and Technology (NIST),
Special Publication 800-90: Recommendation for Random
Number Generation Using Deterministic Random Number Bit
Generators (Revised), March 2007.
Schaad, et al. Expires July 5, 2012 [Page 21]
INTERNET DRAFT CMC Extensions: Server Key Generation January 2, 2012
Appendix A. ASN.1 Module
To be supplied later.
Appendix B. Examples
To be supplied later.
B.1. Client Requests
B.1.1. Shroud with Certificate
B.1.2. Shroud with Public Key
B.1.3. Shroud with Shared Secret
B.2. CA-Generate Key Response
B.3. RA-Generate Key Response
Authors' Addresses
Jim Schaad
Soaring Hawk Consulting
Email: jimsch@exmsft.com
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners@ieca.com
Paul Timmel
National Information Assurance Research Laboratory
National Security Agency
Email: pstimme@tycho.ncsc.mil
Schaad, et al. Expires July 5, 2012 [Page 22]
