Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
draft-ietf-smime-cms-auth-enveloped-06

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>, 
    smime mailing list <ietf-smime@imc.org>, 
    smime chair <smime-chairs@tools.ietf.org>
Subject: Protocol Action: 'Cryptographic Message Syntax (CMS) 
         Authenticated-Enveloped-Data Content Type' to Proposed Standard 

The IESG has approved the following document:

- 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data 
   Content Type '
   <draft-ietf-smime-cms-auth-enveloped-07.txt> as a Proposed Standard

This document is the product of the S/MIME Mail Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-07.txt

Ballot Text

Technical Summary

This document describes an additional content type for the 
Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data 
content type is intended for use with authenticated encryption modes.  
All of the various key management techniques that are supported in the 
CMS enveloped-data content type are also supported by the CMS 
authenticated-enveloped- data content type.
 
Working Group Summary

This document is a product of the smime working group.  The
document follows the style of RFC 3852 (CMS) in describing a content 
type and it's fields.  It is heavily based on an existing content type
(authenticated-data) therefore it is straightforward to understand 
the fields and their use.  The only discussion point on the list was 
the number and location of the authenticated attributes (authAttrs) 
field.  It was argued that the current document, which has one 
authAttrs field after the content, is optimized for the aes-gcm/ccm 
algorithms (see aes-gcm/ ccm draft) and that it would be better to 
have two locations for the authAttr field.

With two fields, efficiencies are afforded to both the current 
algorithms and yet-to-be-defined algorithms that work "faster/better" 
with the authAttrs before the content.  The counter argument against 
two fields was complexity.  The working group determined one field
after the data could adequately support the full range of algorithms
based on tests performed by Peter Gutmann.

Protocol Quality

Tim Polk reviewed this document for the IESG.  There are no current
implementations, although WG members have expressed interest in
implementing this specification.

Note to RFC Editor

Please make the following changes.

In section 3:

OLD:
  accept unsolicited encrypted messages, they become even more
  vulnerable to unwanted traffic since the present mitigation
                                       ^^^
NEW:
  accept unsolicited encrypted messages, they become even more
  vulnerable to unwanted traffic since many present mitigation
                                       ^^^^

In section 2.2:

OLD:
 the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for
                                  ^^^
NEW:
 the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for
                                  ^^^

RFC Editor Note