Subject: Password-based Encryption for S/MIME...

From: Carlisle Adams <[email-masked]>
Date: Wed, 17 Nov 1999 17:23:47 -0500

Hi,

At the meeting last week, Russ solicited more comments on a few of the
current drafts, prior to going to Last Call.  One of the specifically cited
drafts was "Password-based Encryption for S/MIME".  I only have 2 comments
on this draft.

1) "Musts", "shoulds", etc., should be capitalized (this is not absolutely
necessary, but it does help to make conformance requirements clear and
easy-to-find).

2) The Security Considerations section currently contains only the following
sentence:  "The security of this recipient information type rests on the
security of the underlying mechanisms employed, for which further
information can be found in CMS and PKCS5v2."  I suggest adding a new
paragraph along the following lines.

"More importantly, however, the security of this information type rests on
the entropy of the user-selected password, which is typically quite low.
Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED,
although it should be recognized that even with pass phrases it will be
difficult to use this recipient information type to derive a KEK with
sufficient entropy to properly protect a 128-bit (or higher) CEK."

Carlisle.

---

From: Vin McLellan <[email-masked]>
Date: Thu, 18 Nov 1999 16:56:58 -0500

Thank you, Peter.

        My apologies to the list for my apparently out of context note.
<blush> Let this serve as a caution to anyone else who might be tempted to
answer e-mail while flying, when RFCs and suchlike are unavailable. 

                        _Vin

At 09:45 AM 11/19/99, Peter Gutmann wrote:
>
>The title of the document is somewhat misleading, because it's ietf-smime the
>documents are typically called "X for S/MIME" but it's actually "Password-based
>Encryption for CMS", which is what the text refers to it as.  The expected use
>is for encrypting things like disk files, private keys, data blobs, etc etc.  
>In addition there are users who are using things like non-public-key-capable 
>smart cards to handle KEK's (typically 128 or 192-bit values for IDEA or 3DES) 
>which are hardly in the same class as "simple static reusable passwords".