Internet DRAFT - draft-peck-ecdhpop
draft-peck-ecdhpop
INTERNET-DRAFT M. Peck
Intended Status: Proposed Standard The MITRE Corporation
Expires: April 5, 2014 October 2, 2013
Elliptic Curve Diffie-Hellman Proof-of-Possession Method
draft-peck-ecdhpop-01
Abstract
This document specifies a proof-of-possession mechanism for
requesting Elliptic Curve Diffie-Hellman X.509 public key
certificates using the PKCS #10 and CRMF syntaxes.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 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
Peck Expires April 5, 2014 [Page 1]
INTERNET DRAFT Elliptic Curve Diffie-Hellman PoP October 2, 2013
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Peck Expires April 5, 2014 [Page 2]
INTERNET DRAFT Elliptic Curve Diffie-Hellman PoP October 2, 2013
1. Introduction
PKCS #10 [RFC2986] and the Certificate Request Message Format (CRMF)
[RFC4211] are two syntaxes for requesting X.509 public key
certificates.
Public Key Infrastructure (PKI) policies commonly require that
certificate requesters prove possession of the private key
corresponding to the public key in the request.
In the case of a signature certificate request, the requester
typically provides a digital signature, computed using the private
key corresponding to the public key in the certificate request, as
proof of possession.
In the case of a key agreement certificate request, it is possible to
provide proof of possession of the private key by performing a key
agreement operation. However, doing so adds complexity. A simpler
method of providing proof of possession is to perform a one-time
digital signature using the private key.
[RFC6955] defines mechanisms to perform proof-of-possession using a
key agreement operation for Diffie-Hellman and Elliptic Curve Diffie-
Hellman keys, and a mechanism to perform proof-of-possession using a
digital signature for Diffie-Hellman keys. However, it does not
define a mechanism to perform proof-of-possession using a digital
signature algorithm for Elliptic Curve Diffie-Hellman keys.
This document defines a mechanism to perform proof of possession for
Elliptic Curve Diffie-Hellman certificate requests using the Elliptic
Curve Digital Signature Algorithm (ECDSA). This document also
defines how to transmit the proof of possession value using both the
PKCS #10 and CRMF syntaxes.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
2. Elliptic Curve Diffie-Hellman
When using the proof of possession mechanism specified in this
section, Elliptic Curve Diffie-Hellman domain parameters MUST be
selected from a named curve. [FIPS186] names fifteen curves, and
other documents specify other curves.
PKCS #10 and CRMF both use a data element of type
Peck Expires April 5, 2014 [Page 3]
INTERNET DRAFT Elliptic Curve Diffie-Hellman PoP October 2, 2013
SubjectPublicKeyInfo to convey the requested public key. The X.509
certificate, if issued, will contain the public key in a field of the
same type.
[RFC5480] Section 2.1.1 specifies how to represent the Elliptic Curve
Diffie-Hellman domain parameters and public key within the
SubjectPublicKeyInfo data element.
The Elliptic Curve Digital Signature Algorithm is specified in
[FIPS186]. [RFC6090] specifies a signature algorithm called KT-I
that for many hash functions is mathematically and functionally
equivalent to ECDSA. An ECDSA digital signature is generated using a
set of domain parameters (a curve), a private key, a per-message
secret number, a hash function, and the data to be signed.
To use ECDSA to perform proof of possession of an Elliptic Curve
Diffie-Hellman private key:
o Set the ECDSA curve to the same as the ECDH curve.
o Set the ECDSA private key to the same as the ECDH private key.
o Set the ECDSA per-message secret according to the guidance of
[FIPS186].
o Set the hash function depending on the selected curve. The
security strength of the chosen hash function MUST be equal to or
greater than the security strength associated with the bit length of
the domain parameter n. The security considerations section of
[RFC5480] provides recommended hash functions to use in conjunction
with the NIST curves.
o Set the data to be signed according to the guidance provided by
PKCS #10 or CRMF.
For PKCS #10, set the signatureAlgorithm field to the appropriate
ECDSA signature algorithm object identifier depending on the hash
function chosen above, and place the generated ECDSA signature in the
signature field, following the guidance of [RFC3279] Section 2.2.3.
For CRMF, include the popo field within CertReqMsg using the
signature (POPOSigningKey) proof-of-possession choice. Set the
POPOSigningKey algorithmIdentifier to the appropriate ECDSA signature
algorithm object identifier depending on the hash function chosen
above, and place the generated ECDSA signature in the POPOSigningKey
signature field, following the guidance of [RFC3279] Section 2.2.3.
[RFC3279] and [RFC5758] provide ECDSA signature algorithm identifiers
Peck Expires April 5, 2014 [Page 4]
INTERNET DRAFT Elliptic Curve Diffie-Hellman PoP October 2, 2013
paired with various hash functions. Additional ECDSA signature
algorithm identifiers may be found in other sources.
3. Security Considerations
This document specifies proof-of-possession of a key agreement
private key by performing a digital signature. Except for one-time
proof-of-possession, a single key pair SHOULD NOT be used for both
signature and key agreement. NIST Special Publication 800-57 Part 1
[SP80057] Section 8.1.5.1.1.2 permits use of a key agreement private
key to perform a digital signature for proof-of-possession purposes.
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. [FIPS186] and
[RFC4086] offer random number generation guidance.
In a substitution attack, as described in [RFC5272] Section 6.3, an
attacker may attempt to take a PKCS #10 or CRMF certificate request
and change the context in which it is presented to the Certification
Authority in order to cause a certificate with incorrect identity
information to be generated. In order to thwart this class of
attack, the proof-of-possession signature should cover not only the
public key itself but also on the requested identity or other
information used by the public key infrastructure to assign an
identity to the issued certificate. For example, CMC [RFC5272]
provides a mechanism to cryptographically bind information from the
outer Full PKI Request into the inner PKCS #10 or CRMF message where
it is covered by the proof-of-possession signature. The EST protocol
[est] provides a similar mechanism to cryptographically bind
information from the TLS session into the inner PKCS #10 or CRMF
message where it is covered by the proof-of-possession signature.
4. IANA Considerations
This document has no IANA actions.
5. References
5.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[FIPS186] National Institute of Standards and Technology, FIPS
Publication 186-4: "Digital Signature Standard (DSS)",
July 2013.
Peck Expires April 5, 2014 [Page 5]
INTERNET DRAFT Elliptic Curve Diffie-Hellman PoP October 2, 2013
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
November 2000.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
5.2. Informative References
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, January 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6955] Schaad, J., and H. Prafullchandra, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 6955, May 2013.
[SP80057] National Institute of Standards and Technology, Special
Publication 800-57 Part 1: "Recommendation for Key
Management - Part 1: General (Revision 3)", July 2012.
[est] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over
Secure Transport", draft-ietf-pkix-est-09, Work in
Progress, August 2013.
Peck Expires April 5, 2014 [Page 6]
INTERNET DRAFT Elliptic Curve Diffie-Hellman PoP October 2, 2013
Authors' Addresses
Michael Peck
The MITRE Corporation
EMail: mpeck@mitre.org
Peck Expires April 5, 2014 [Page 7]
