Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
RFC 5083

Note: This ballot was opened for revision 06 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Sam Hartman) Yes

Comment (2007-09-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I still believe the paragraph about generic pre-computation attacks in
the security considerations section is misleading and the document
would be approved by citing the specific attacks David mentioned in
his mail.  This is a really minor issue and I understand if you disagree.

Having read the text, I definitely think Jari's concern about the
ASN.1 is valid.  I suggest replacing explicit set of tag with "the
universal tag for the set of type".

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2007-09-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Boilerplate text on IPR is missing?

(Cullen Jennings) No Objection

Comment (2007-09-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
A helpful addition to this draft would be an appendix with one example messages.

(Chris Newman) (was Discuss) No Objection

Comment (2007-09-20)
No email
send info
Here's a rough attempt to describe the threat and mitigation:

A significant security threat to messaging environments today involves
various forms of unsolicited messages (spam and phishing).  Present
mitigation strategies for this threat involve analysis of message
plaintext by fingerprint engines that typically require access to
proprietary infrastructure on the Internet or intranet.  CMS recipients
that accept unsolicited encrypted messages are vulnerable to such
attacks and CMS defeats many common mitigation strategies.  Software
that receives encrypted CMS messages MUST provide a mechanism to
counter the threat of unsolicted messages.  One approach is to reject
or discard encrypted messages unless they meet some reasonable
definition of solicited (for example, if the validated originator is
present in the recipient's personal or corporate addressbook).  An
alternative approch would provide a client mechanism to call out to
a server-based service that filters for such inappropriate content.

Thankfully, CMS clients are not widely deployed enough (or easy enough
to use) for this threat to manifest yet.  But if continued work to
improve CMS support changes that situation we need to be prepared
for the most likely attack on the system.  IMHO, an in depth
discussion of the _many_ approaches to mitigation is
out-of-scope for this document and for IETF standards.

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection

(Russ Housley) Recuse