Subject: RE: WG Last Call:draft-ietf-smime-cms-07.txt

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 2 Nov 1998 12:39:31 -0800

I was in the middle of writing a long message to Steve that he did not
understand how things were working when I found out that I was the one
laboring under a mis-impression of how things worked and he was infact
write.  And I'm pissed about this.

I had completely missed the sentences that put restrictions on the message
encryption algorithm if certain transport algorithms are used.  I THINK THIS
IS WRONG!!!!!  If I had understood at the time that this was the proposal I
would have been very vocal about this.  This was introduced post draft 3 of
section 12 on the list.  I may have just missed it.

I do not understand or want any ties between the key transport and the
message encryption unless they are absolutely necessary.  This makes my
message list agent process more difficult.  In the past all it needed to do
was the re-write the receipient infos and it was done.  (Except for the
possible problems of high/low encryption issues.)  Now it will almost
certianly need to decrypt and re-encrypt the message for anybody using RC2.
There is not a single existing S/MIME client which uses RC2 in the way
described in CMS.  The two different ways I know are to either generate the
same number of key bits as key size (Microsoft and Netscape) or to generate
a fixed number of key bits at 196 (WorldTalk).  Neither of these messages
can be forwarded intact if any D-H key transport is to be done.

Given this I STRONGLY suggest that we
1)  remove the offending sentences
2)  keep the fixed 128-bit keys size when creating the key wraping key
3)  fix the wraping algorithm by adding a known padding mechisim.  (Three
alternatives: a) add a size byte, b) use the standard content encryption
alg, c) use a modified PKCS#1 with a NULL byte followed by random pad)

jim schaad

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 02 Nov 1998 23:26:21 +0000

Jim Schaad (Exchange) wrote:
[Stuff suggesting one seriously annoyed Jim deleted]
> section 12 on the list.  I may have just missed it.

Speaking personally I can live with things as suggested. However they
would make my life bloody difficult and I'd rather not have to.

> alg, c) use a modified PKCS#1 with a NULL byte followed by random pad)

I agree with all that and again speaking personally I'd go with b) for
the following reasons.

Certain libraries have the separate algorithms corresponding to "raw"
and "padded" versions: for example in PKCS#11 we have CKM_RC2_CBC and
CKM_RC2_CBC_PAD (this uses padding compatible with standard content
encryption padding described in CMS 6.3).

As things stand there would be two seprate versions, RC2 as used for
content encryption (with padding) and RC2 as used in key wrap (no
padding). If we take option b) then we consistently end up with the same
padding used for both wrapping and content encryption. As a nice side
effect this also allows the key length to be determined unambiguously.
If adding pseudo-random bytes is still considered necessary then adding
a fixed number (e.g. one block length) still allows the key length to be
determined.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.