Document Action: 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' to Informational RFC (draft-herzog-static-ecdh-06.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux