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