Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
RFC 5083
Approval announcement
Draft of message to be sent after approval:
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
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 ^^^