Internet Engineering Task Force (IETF) J. Herzog
Request for Comments: 6278 R. Khazan
Category: Informational MIT Lincoln Laboratory
ISSN: 2070-1721 June 2011
Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in
Cryptographic Message Syntax
Abstract
This document describes how to use the 'static-static Elliptic Curve
Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-
Hellman where both participants use static Diffie-Hellman values)
with the Cryptographic Message Syntax. In this form of key
agreement, the Diffie-Hellman values of both the sender and receiver
are long-term values contained in certificates.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6278.
Herzog & Khazan Informational [Page 1]
RFC 6278 Static-Static ECDH in CMS June 2011
Copyright Notice
Copyright (c) 2011 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 ....................................................2
1.1. Requirements Terminology ...................................5
2. EnvelopedData Using Static-Static ECDH ..........................5
2.1. Fields of the KeyAgreeRecipientInfo ........................5
2.2. Actions of the Sending Agent ...............................6
2.3. Actions of the Receiving Agent .............................7
3. AuthenticatedData Using Static-Static ECDH ......................8
3.1. Fields of the KeyAgreeRecipientInfo ........................8
3.2. Actions of the Sending Agent ...............................8
3.3. Actions of the Receiving Agent .............................9
4. AuthEnvelopedData Using Static-Static ECDH ......................9
4.1. Fields of the KeyAgreeRecipientInfo ........................9
4.2. Actions of the Sending Agent ...............................9
4.3. Actions of the Receiving Agent .............................9
5. Comparison to RFC 5753 ..........................................9
6. Requirements and Recommendations ...............................10
7. Security Considerations ........................................12
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
1. Introduction
This document describes how to use the static-static Elliptic Curve
Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-
Hellman [RFC6090] where both participants use static Diffie-Hellman
values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS
is a standard notation and representation for cryptographic messages.
The CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define
Herzog & Khazan Informational [Page 2]
RFC 6278 Static-Static ECDH in CMS June 2011
a number of structures that carry both cryptographically protected
information and key-management information regarding the keys used.
Of particular interest here are three structures:
o EnvelopedData, which holds encrypted (but not necessarily