Subject: LAST CALL:draft-ietf-smime-password-02.txt

From: Russ Housley <[email-masked]>
Date: Mon, 13 Mar 2000 15:15:34 -0500

The Password-based Encryption for S/MIME specification is ready for Working 
Group Last Call.  Please post comments to the ietf-smime mail list before 
27 March 2000.

Russ

= = = = = = = = = =

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-02.txt
	Pages		: 9
	Date		: 10-Mar-00
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 27 Mar 2000 17:03:35 +0930

Here are the set of last call comments that I have for this draft.

1.  You still have a reference to PKCS #5 v2 in the document. (PKCS#5 v2 is
not an information or other RFC.)  If you want this document to be on
standards track rather than informational then this issue needs to be
resolved.

2.  Section 2.1.  The S/MIME working group is using 88 ASN syntax.  The
syntax in this section is not.  Please correct.

<previous response from peter>
PKCS #5 uses current ASN.1 syntax and not the 1988 version, the ASN.1 used
is taken straight from the standard.

3.  Section 2.1  Why is there ASN here that does not actually provide any
useful information.  What are the parameters.  What is the OID associated
with this set of parameters.  This is an issue for both the fact that PKCS#5
is not an RFC and the ASN.1 is not 1988.

<previous response from peter>
It's copied from PKCS #5 for completeness, I didn't want to include the
whole thing verbatim but did want to include enough information that readers
wouldn't have to keep flipping back and forth between the two.

4.  Section 2.3.1 - I will raise the issue of the fact that the key wrap
algorithm is not the same as CMS even though the CMS version is a MUST
implement.  At a minimum you should make the CMS version the MUST and the
version you have in your document an optional version to have.

5.  Based on a past email with Carlisle Adams, I think that changing title
to "Password-based Encryption for CMS" is a reasonable thing to do.

6.  Why does a version with keyDerivation optional exist in this draft?  It
appears to me that this is exactly the same thing as is done by
kekRecipientInfo (i.e. an existing KEK key is used to wrap a CEK key).  I
would not be in favor of having two different methods for doing this.

7.  I don't understand why onlyi the first 3 bytes of the CEK are used for
the checksum.  What is the problem with using the first 3 bytes of a SHA1
hash.  I don't think the performance difference is going to be significant.

8.  The test vectors should be modified to use one of the standard CMS
algorithms if they are going to be present in the draft.  Blowfish is not an
algorithm that one should expect most CMS developers to have implemented.
RC2 and 3DES are.

jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Mar 2000 05:32:42 -0500

Peter:

One of the first decisions that the S/MIME working group made was to use 
1988 ASN.1.  This decision was made for several reasons, including the 
availability of compilers.  So, if you want this to move forward as part of 
the S/MIME Standards Track document series, then you will have to reverse 
port the ASN.1.

Russ