"Jim Schaad (Exchange)" <jimsch(_at_)Exchange(_dot_)Microsoft(_dot_)com> writes:
3. Section 2.1 Why is there ASN here that does not actually provide any
useful information. What are the parameters. What is the OID associated
with this set of parameters.
It's copied from PKCS #5 for completeness, I didn't want to include the
whole thing verbatim but did want to include enough information that readers
wouldn't have to keep flipping back and forth between the two.
I believe that you failed at this. There is not enough information in this
draft to know anything. For all of the good what is there did me, you might
as well have omitted it entirely for all of the good it did me when reading
the draft.
I can't include all of PKCS #5 (it's thirty pages long even when it's in a
proportional font), and I can't omit it entirely either because something other
than PKCS #5 may at some point define key derivation algorithms and you need to
have somewhere to list them. Do you have any suggestions about what I could
replace the current text with? I can't drop the ASN.1 because it's needed in
Appendix A to define/constrain the algorithm(s) used.
Also given that the new CAST and IDEA drafts both use the RFC2630 key
wrapping algorithm makes me believe that it is easily extendable to any
algorithm.
The reason they use the new algorithm is because the AlgorithmIdentifier it
requires is completely incompatible with any existing one, so that no existing
cipher can be used with CMS without an update of whatever standard they're
defined in. The only reason the new CAST and IDEA drafts exist is to define
this new AlgorithmIdentifier (if you don't believe me, check the drafts again -
the existence of the RFC2630 algorithm is requiring people to write custom
drafts to accomodate it). Once CAST and IDEA are updated, we also need to
update the standards for RC5, DES, Skipjack, Misty, Blowfish, and every other
algorithm which anyone might want to use with their own personal "Use of the
<foo> Encryption Algorithm in S/MIME" draft. Even then it's not going to work
in many cases because the standards only define X-in-X wrap, not X-in-Y wrap.
The example I gave in a previous message (3DES CEK wrapped in an IDEA KEK held
in a smart card) can't be done with RFC 2630, and the example I use in my draft
(80-bit key wrapped in a 192-bit key, with a note elsewhere to say that this
isn't a good match :-) can't be done either, because neither Skipjack nor
3DES-in-Skipjack drafts have been written to define what's necessary for RFC
2630.
That's an interesting statement. I explicitly worked with Russ to make sure
that we could do variable length RC2 keys using the key wrap algorithm from
RFC 2630.
Parts of it don't seem terribly variable, for example RFC 2630, section
12.3.3.2, says:
Only 128-bit RC2 keys may be used as key-encryption keys, and they
must be used with the RC2ParameterVersion parameter set to 58.
which doesn't seem to allow for much variation (see the comments further down
for more).
I understood that the RC2 CEK algorithm was changing from 1.2.840.113549.3.2
to 1.3.6.1.4.1.3029.666.13 (provesional)
I wanted to make sure that even someone who hadn't read the spec would get the
hint that this was something they should be avoiding :-). The only reason that
OID is necessary is to handle implementations which do unexpected things with
key lengths (previously you've had to use guesswork or rely on PKCS #1 padding
to tell you how many bytes you had on hand or whatever, I wanted to provide
something a bit more rigorous).
in the event that the effective key size and actual key size did not match.
This means that if I am doing a password KEK and an RSA key transport, the
value is not well defined depending on which one I meant to use. If this is
not what you meant then please clarify. My reasoning went as following:
1. CEK key length is obtained from the CEK algorithm description
2. The new algoirthm parameters contain the actualKey lenght and must
therefore be part of the CEK.
3. All other code that uses CMS needs to understand this new CEK algorithm
in the event that a password receipient is included.
OK, to go through the various parameters (from RFC 2630, "actual" = no.bits
before RC2 mangling, "effective" = no.bits after RC2 mangling):
CEK actual: For RSA, given in PKCS #1 padding or guesswork or whatever
people are using now.
CEK effective: Given in content-encryption OID.
PW-KEK actual, effective: Either RFC 2268 default or as per the kludge OID
if you want to use nonstandard values.
I can't see why all other code needs to know about the PW-KEK, it can just keep
on using the KeyTrans information as before. I can see that there's one
possible parameter which I haven't allowed for in PW-KEK (the CEK actual rather
than effective size), if people are worried that some implementation will want
to do odd things to this as well then it can be added to the kludge OID too, so
you have four different key size parameters you can vary with RC2. If that's
necessary then I might have to insist that more values like the current '666'
and '13' be added to the OID as a warning to implementors.
Peter.