Subject: Re: Comments on draft-ietf-smime-password-00

From: [email-masked] (Peter Gutmann)
Date: Fri, 19 Nov 1999 10:53:43 (NZDT)

"Jim Schaad (Exchange)" <[email-masked]> writes:

>1. Section 2.1.  What is the timing you expect to see relative to PKCS5v2
>being advanced to an RFC of some type?

I have no idea.  Does it need to be?  Like the other PKCS's I assume it can
be turned into an RFC in no time, but is that a requirement?

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

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.

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  We have a key wrap algorithm specified in RFC 2630.  You
>are using a different key wrap algorithm.  I would prefer to see a single
>one for simplity of implementation.  What is your justification for added
>complexity?

The RFC 2630 algorithm doesn't work for anything other than fixed-length RC2
and 3DES keys.  This algorithm works with anything (well, anything with an OID
defined, which in practice means pretty much any commonly-used algorithm).
It's also a lot simpler than the RFC 2630 algorithm, you just run any old
block cipher over the data twice without needing additional hashing, byte-
reversal, or anything else - if all you've got to do your crypto is a smart
card which does 3DES (eg Gemplus' MPCOS) or IDEA (see my previous message) you
can't even implement the RFC 2630 algorithm.

[I assume that when you're saying you can use 256 bits of key for a 128-bit
 algorithm what you mean is that you have 256 bits of actual key which is
 transformed to 128 bits of effective key by the RC2 key-transformation].

The same thing occurs with RFC 2630 and it doesn't seem to be a problem there.
In any case I think I've addressed it in "Special Handling for RC2 Keys".

>6.  Sectoin 2.3.1.  Questions  about your algorithm:  1) what is the IV that
>should be used initially on the first pass encryption (not explicity stated
>but implied later).  2) Where is the IV saved?

It's part of the AlgorithmIdentifier for the KEK algorithm.  I assumed it
wouldn't be necessary to mention this because it's the standard usage for an IV
given in the AlgorithmIdentifier, but I can move the text in the example
(2.3.3, "Using the IV given in the KeyEncryptionAlgorithmIdentifer...") up to
2.3.1 if the current text isn't clear.

>3) What does step 1 of section 2.3.2 do?  I don't see a corresponding step
>in section 2.3.1.

It recovers the IV used for the second pass of encrption (step 3 of 2.3.1).

>This thing might work, but I should don't believe it from just reading the
>document.

I would hope it does, or the people who have been using it almost daily since
it was first published in 1993 are in for a rude shock :-).

>7.  Section 2.3.4 -- Can this issue also be addressed by the addition of a
>random salt to the KEK creation process?  This means one is not using the
>same KEK for every CEK encrption from a single password.

PKCS #5 already adds the salt, however I wanted to create a failsafe design
which works even if no salt (or a fixed salt) is used.  The double-wrapping
also prevents bit-flipping attacks, I'll amend the text to mention this.

>8.  Section 2.4.1 -- You cannot change the CEK for RC2 in this document.  I
>don't want two different versions for this depending on wheither I have a
>Password KEK mixed in the set of recipients.  This just will not fly.

Uhhh... I don't understand the comment.  How can you have two different CEK's
for the same data?

Peter.

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Nov 1999 15:43:39 -0500

>be turned into an RFC in no time, but is that a requirement?

If you want this on the standards track this will greatly ease progression.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Nov 1999 15:46:14 -0500

>is taken straight from the standard.

Since there are many tools that support ASN.1-1998, and there are very few 
tools that support ASN.1-1993, we use ASN.1-1998 in all S/MIME standards 
track documents.  Remember that interoperable implementations from 
different code bases are required for progression from Proposed Standard to 
Draft Standard.

Russ