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

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 09:45:31 -0800

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

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

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.

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?

5.  Section 2.3.2.  You state that the length of the key can be determined
from the CEK parameters.  This is not always true.  A counter example would
be to use 256-bits of key material for a RC2/128-bit process.  In this case
you would only pull 128-bits of key material and be unable to decrypt the
content.

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?  3) What does step 1 of
section 2.3.2 do?  I don't see a corresponding step in section 2.3.1.  This
thing might work, but I should don't believe it from just reading the
document.

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.

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.

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 15:16:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> "Jim Schaad (Exchange)" <[email-masked]> writes:
> 
> 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?

It is my understanding that if you want this document to following standards
track, you are not going to be able to reference a non-fixed document.  The
PKCS documents have not meet that criteria in the past and thus the reason
why we got them published as informational to get the S/MIME v2 drafts in.
I believe this is also a requirement for publishing the password draft as
informational as well but am not sure.  Therefore this is a blocking factor
for moving the document forward.

> PKCS #5 uses current ASN.1 syntax and not the 1988 version, 
> the ASN.1 used
> is taken straight from the standard.
> 
> 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.

I believe that you failed at this.  There is not enough information in this
draft to know anything.  For all of the good what is there did me, you might
as well have omitted it entirely for all of the good it did me when reading
the draft. 

> 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".
> 

That's an interesting statement.  I explicitly worked with Russ to make sure
that we could do variable length RC2 keys using the key wrap algorithm from
RFC 2630.  I find it difficult to believe that your algorithm is "much"
simpler than the one in RFC2630 given the partial decryptions and so forth.
(I don't know it is really alot harder either.)  Given that most people
implemented the one in RFC2630 in a couple of hours at most I don't see that
complexity of implemenation is real hard.  Also given that the new CAST and
IDEA drafts both use the RFC2630 key wrapping algorithm makes me believe
that it is easily extendable to any algorithm.

> >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 :-).
> 
> 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.
> 
> Uhhh... I don't understand the comment.  How can you have two 
> different CEK's
> for the same data?

I understood that the RC2 CEK algorithm was changing from 1.2.840.113549.3.2
to 1.3.6.1.4.1.3029.666.13 (provesional) in the event that the effective key
size and actual key size did not match.  This means that if I am doing a
password KEK and an RSA key transport, the value is not well defined
depending on which one I meant to use.  If this is not what you meant then
please clarify.  My reasoning went as following:
1.  CEK key length is obtained from the CEK algorithm description
2.  The new algoirthm parameters contain the actualKey lenght and must
therefore be part of the CEK.
3.  All other code that uses CMS needs to  understand this new CEK algorithm
in the event that a password receipient is included.

> Peter.

jim

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 19 Nov 1999 13:45:35 (NZDT)

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

>>I have no idea.  Does it need to be?  Like the other PKCS's I assume it can

I've cc'd this to the PKCS editors address to get their comments on this, 
RFC 231[345] are all informational RFC's which are just the PKCS originals 
with RFC boilerplate, if that's required then it shouldn't be too hard to do
the same for PKCS #5v2.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 19 Nov 1999 16:30:19 (NZDT)

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

>>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

I can't include all of PKCS #5 (it's thirty pages long even when it's in a
proportional font), and I can't omit it entirely either because something other
than PKCS #5 may at some point define key derivation algorithms and you need to
have somewhere to list them.  Do you have any suggestions about what I could
replace the current text with?  I can't drop the ASN.1 because it's needed in
Appendix A to define/constrain the algorithm(s) used.

>Also given that the new CAST and IDEA drafts both use the RFC2630 key
>wrapping algorithm makes me believe that it is easily extendable to any
>algorithm.

The reason they use the new algorithm is because the AlgorithmIdentifier it
requires is completely incompatible with any existing one, so that no existing
cipher can be used with CMS without an update of whatever standard they're
defined in.  The only reason the new CAST and IDEA drafts exist is to define
this new AlgorithmIdentifier (if you don't believe me, check the drafts again -
the existence of the RFC2630 algorithm is requiring people to write custom
drafts to accomodate it).  Once CAST and IDEA are updated, we also need to
update the standards for RC5, DES, Skipjack, Misty, Blowfish, and every other
algorithm which anyone might want to use with their own personal "Use of the
<foo> Encryption Algorithm in S/MIME" draft.  Even then it's not going to work
in many cases because the standards only define X-in-X wrap, not X-in-Y wrap.
The example I gave in a previous message (3DES CEK wrapped in an IDEA KEK held
in a smart card) can't be done with RFC 2630, and the example I use in my draft
(80-bit key wrapped in a 192-bit key, with a note elsewhere to say that this
isn't a good match :-) can't be done either, because neither Skipjack nor
3DES-in-Skipjack drafts have been written to define what's necessary for RFC
2630.

>RFC 2630.

Parts of it don't seem terribly variable, for example RFC 2630, section
12.3.3.2, says:

  Only 128-bit RC2 keys may be used as key-encryption keys, and they
  must be used with the RC2ParameterVersion parameter set to 58.

which doesn't seem to allow for much variation (see the comments further down
for more).

>to 1.3.6.1.4.1.3029.666.13 (provesional)

I wanted to make sure that even someone who hadn't read the spec would get the
hint that this was something they should be avoiding :-).  The only reason that
OID is necessary is to handle implementations which do unexpected things with
key lengths (previously you've had to use guesswork or rely on PKCS #1 padding
to tell you how many bytes you had on hand or whatever, I wanted to provide
something a bit more rigorous).

>in the event that the effective key size and actual key size did not match.
>This means that if I am doing a password KEK and an RSA key transport, the
>value is not well defined depending on which one I meant to use.  If this is
>not what you meant then please clarify.  My reasoning went as following:

OK, to go through the various parameters (from RFC 2630, "actual" = no.bits
before RC2 mangling, "effective" = no.bits after RC2 mangling):

  CEK actual: For RSA, given in PKCS #1 padding or guesswork or whatever
        people are using now.
  CEK effective: Given in content-encryption OID.
  PW-KEK actual, effective: Either RFC 2268 default or as per the kludge OID
        if you want to use nonstandard values.

I can't see why all other code needs to know about the PW-KEK, it can just keep
on using the KeyTrans information as before.  I can see that there's one
possible parameter which I haven't allowed for in PW-KEK (the CEK actual rather
than effective size), if people are worried that some implementation will want
to do odd things to this as well then it can be added to the kludge OID too, so
you have four different key size parameters you can vary with RC2.  If that's
necessary then I might have to insist that more values like the current '666'
and '13' be added to the OID as a warning to implementors.

Peter.

---

From: "Kaliski, Burt" <[email-masked]>
Date: Fri, 19 Nov 1999 13:13:31 -0500

A couple issues with the proposed RFC version of PKCS #5 v2 draft needed to
be resolved, we should be submitting a revised version shortly. Thanks for
the encouragement.

-- Burt Kaliski
RSA Laboratories

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 19, 1999 8:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-smime-password-00

Peter.