Eric & Steve
I would like to keep the key wrap algorithm as simple as possible. It is
getting too complex already.
Perhaps the key agreement AlgorithmIdentifier should have two paramters,
both AlgorithmIdentifiers. One alg id tells the key agreement technique
and the second tells the key wrap technique. This should make it more
flexible for the future.
At 03:13 PM 10/4/98 -0700, EKR wrote:
Dr Stephen Henson <shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk>
Eric Rescorla wrote:
Russ has requested that I summarize the results of the RC2 keylength
strawpoll and close out this issue. Unfortunately, the strawpoll
reached no clear consensus. (It's pretty much dead even).
Consequently, we're going to leave things more or less as-is. RC2
keys MUST be 16 octets, both when used as KEKs (the output of DH
computations) and MEKs. Implementations SHOULD accept other length
MEKs when RSA encrypted, in the interest of backwards compatibility.
If you have an objection to this (admittedly flawed) decision
procedure (I.e. I as document editor just decide), speak up now.
This isn't the time for substantive technical argument, however.
Fair enough. Just a few comments.
For the record what was the actual result?
IMHO CMS needs a specific comment re RC2. Currently it doesn't
specifically exclude RC2 with keylength > 128 in DH.
Fair enough. Paul, Can you add the appropriate ocmment?
Is this going to apply to the other two possibilities, E-S and S-S DH?
That's what it's intended to apply to, yes. As you know, DH
is the case that creates this problem in the first place.
There was never any mention of why the key wrapping standard or CMS
couldn't be changed to allow the MEK length to be determined explicitly
and thus enable current RSA implementations to be unchanged in mixed RSA
and DH environments.
Correct. This could be done and it's a separate issue.
I'd argue against it on consistency grounds, but I'm not
violently opposed to it. Perhaps Russ would like to weigh in,
since wrapping is really his document.
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]