Tim:
1) I know this is a stupid question because this has been accepted as a
given by the WG for quite a bit of time, but why is S/MIME using the
Diffie-Hellman algorithm, which requires a bit of wedging to work as a
store-and-forward key transport algorithm, rather than ElGamal? Note that
this proposal is basically identical to ElGamal, only it uses 3DES and a
checksum instead of modular multiplication and PKCS#1-style padding.
With ElGamal, I do not think that the originator has a static public value
that can be placed in a certificate. With the proposed variant of
Diffie-Hellman, the originator uses a static component that is included in
a certificate, and therefore, the recipient knows who the other party is
that holds the pariwise key.
2) Unless S/MIME is only going to support 3DES, it seems that there must be
a method capable of wrapping keys other than 3DES keys. Is that the intent?
Why not just create a single wrapping mechanism for all kinds of keys?
(Note that this comment has nothing to do with the selection of 3DES as a
wrapping mechanism, just the fact that it wraps only 3DES keys.)
Others have recommended a generic key wrap mechanism too. And, over the
last week I have given this a fair amount of thought. While I am not
opposed to such a scheme, it is quire a few more larger than necessary. In
fact it would probably have to have a structure similar to:
EncryptAlgId, IV, ENCRYPT ( Salt, KeyAlgId, Key, IntegrityAlgId,
IntegrityValue, Pad )
Steve Farrell suggested the addition of a salt to the scheme I described,
and it certainly cannot hurt.
I am not necessarily opposed to such a structure, but there are other
policy concerns too. For example, can a strong key be encrypted with a
weaker one (e.g., 3DES wrapped by DES)? Should such policy be addressed?
Defining a 3DES specific key wrap allows a more efficient (fewer bits)
solution does not not delay the S/MIME 3 while policy issues are discussed.
3) Is 16 bits the appropriate place to trade off the work factor for
causing a checksum collision with the overhead per recipient? Why not 8, or
24? (I don't have a problem with 16, I was just interested in why that
value precisely.) (Note that the work factor is actually 2^19, thanks to
the requirement that the resultant keys must have odd parity.)
This is one of the areas where I was looking for review. On the FORTEZZA
card, when an 80 bit SKIPJACK key is wrapped, the result is 96 bits long.
So, if 16 bits is sufficient for an 80 bit key, I figured it was in the
right ballpark. especially with the parity bits associated with each octet.
4) You may want to clarify step 3a of the key checksum algorithm to "Create
a 16 bit integer, called temp, by setting the high 8 bits to zero and the
low 8 bits to the key octet." to avoid (probably unreasonable) endian-ness
confusion.
An example in the final document should resolve this concern, since it is
well known which bit int the DES key octets are used for parity.
Russ