Skip to main content

Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
draft-turner-ekpct-algs-update-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type' to Proposed Standard (draft-turner-ekpct-algs-update-03.txt)

The IESG has approved the following document:
- 'Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS)
   Encrypted Key Package Content Type'
  (draft-turner-ekpct-algs-update-03.txt) as a Proposed Standard

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-turner-ekpct-algs-update/


Ballot Text

Technical Summary

This document describes conventions for using Elliptic Curve
cryptographic algorithms with SignedData and EnvelopedData to protect
the AsymmetricKeyPackage content type. Specifically, it includes
conventions necessary to implement Elliptic Curve Diffie-Hellman
(ECDH) with EnvelopedData and Elliptic Curve Digital Signature
Algorithm (ECDSA) with SignedData. This document updates RFC 6033.

Note that downrefs to RFC 5753 and draft-mcgrew-fundamental-ecc (now
RFC 6090) were called out and received no comment.  They have now
been added to the downref registry.

Working Group Summary

As noted earlier, this draft is not the product of a WG. It's also very
short as there are essentially only three statements in the document:
ECDDSA is MAY, ECDH is MAY, and P-256 is a MUST if you do either.

Document Quality

There are no known implementations of this document.

Personnel

Sean Turner <turners@ieca.com> is the document Shepherd.
Tim Polk <tim.polk@nist.gov> is the responsible Area Director.

RFC Editor Note

In section 3

s/EncryptedKeyPacakge/EncryptedKeyPackage/



RFC Editor Note