The IESG has approved the following document: - 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' (draft-herzog-static-ecdh-06.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ Technical Summary This document describes how to use 'static-static' Elliptic Curve Diffie-Hellman (S-S ECDH) key-agreement with the Cryptographic Message Syntax (CMS). In this form of key-agreement, the Diffie-Hellman values of both sender and receiver are long-term values contained in certificates. This form of key agreement can be used with three CMS content types: EnvelopedData, AuthenicatedData, and AuthEnvelopedData. Working Group Summary This is not the product of a WG, but it was discussed on the SMIME WG mailing list. This draft documents an option not in RFC 5753 (Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)). RFC 5753 specifies the use of ephemeral-static (E-S) ECDH, but does not specify the use of S-S ECDH. The SMIME WG did not specify S-S ECDH because E-S ECDH is more secure (to save you some time: E-S ECDH provides better security due to the originator's ephemeral contribution to the key agreement scheme). This is not to say S-S ECDH is insecure it's just that E-S ECDH is considered more secure and there was only a limited amount of energy to work on ECDH based solutions. Note that draft-herzog-static-ecdh contains a section that compares itself to RFC 5753. The discussion on the WG list was light. Jim Shaad provided reviews that resulted -01. -02, -03 and -04 were to address ID-nits. Document Quality There is an implementation of an earlier version of this document. This implementation can be updated with little effort to match this version of the final document. Personnel Jonathan Herzog <jherzog@ll.mit.edu> is the document Shepherd. Tim Polk is the responsible Area Director. RFC Editor Note Please append the following paragraph to Section 7, Security Considerations: When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption would not be possible by the sender's infrastructure (though it would remain possible for the infrastructure of any recipient.) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
