ietf-smime
[Top] [All Lists]

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

2000-03-27 00:31:57
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


<Prev in Thread] Current Thread [Next in Thread>