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
^^^