"Jim Schaad (Exchange)" <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com> writes:
1. Section 2.1.2 in the paragraph on pubInfo: There is a description that
appears to say CMS defined UserKeyingMaterial as a 512-bit value. There are
two problems with this: a) CMS does not say anything about the length of ukm
and b) no justification is shown here for a length of 512-bits. Is this a
magic length?
I'm trying to remember myself. ISTR that some previous CMS version
had 512 bits. I'm not fixated on this number by any means.
IIRC, KEA uses 512 bits.
2. Section 2.1.4: Please append the following or something similar. "Note:
RC2 is restricted to effective key lengths of 128-bits or fewer. Expansion
of 128-bits of input key to a 256-bit effective key length does not add any
additional security."
Will do.
3. Section 2.1.6: I don't recognize the 3DES oid that you have here. I
was expecting to see "06 09 1a 86 48 86 f7 0d 03 07" with a comment of
"DES-EDE3-CBC OID"
4. Section 2.1.7: The counter is incorrect.
Yes The examples are wrong. Stephen Henson and I have now
agreed on an example set that will go out in the next revision.
5. Section 2.2: I think we need to change the value of m. If we are
suggesting a value of m for DES and CMS is saying that 3DES is the manditory
algorithm, then we are not making any sense. I think that we need to have a
value of m which is appropriate for 3DES, and potentially a rule of thumb
for shorter key lengths.
Correct. See my previous comments on this topic in my message to
Russ. I'm concerned about the parameter generation algorithm.
6. Section 2.1.5: This section ends with the phrase "may not be
necessary". This gives no information to make an intellegient guess if this
is required or not. Can we add some text about why it would or would not be
a good idea to do this?
I'll try to produce some.
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]