Russ Housley wrote:
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.
What I was personally suggesting would make almost no changes to the
wrapping spec: more a modification than an additional complication. Two
ideas sprang to mind:
Currently we have in the spec:
"5. Generate the number of pad octets necessary to make the
result a multiple of the key-encryption algorithm block
size, then append them to the result."
If this is modified to:
"5. Pad the result using standard block padding (as described in
CMS 6.3) to make the result a multiple of the key-encryption
algorithm block size, then append them to the result."
with corresponding decoding the MEK length can be determined
unambiguously. This would apply to all cases: it is needed for RC2 but
it could perform an additional integrity check in other cases.
This might even simplify things because some crypto libraries have
separarate (for example) "XXX" and "XXX with padding" algorithms. Since
the content encryption involves the "XXX with padding" form this would
mean that only "XXX with padding" algorithms would be used throughout.
The other alternative would be to simply have an OPTIONAL MEKlength
INTEGER parameter in CMS which would only be present for variable key
length algorithms whose key length is not specified in the
AlgorithmIdentifier: this probably means just RC2.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.