The IESG has approved the following document: - 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type ' <draft-ietf-smime-cms-auth-enveloped-06.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 Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-06.txt 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 ^^^ _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
