Hi Jim,
Thanks for reviewing this.
1. I would like to see a section added to section 2 to describe why this
"trick" is being used rather than just establishing a short-term kek value
which is used for a time period and then tossed. I.e. When do you use this
trick and when do you establish a multi-use kek value.
Not clear to me - "establishing a short-term kek value" how? If you mean
I should say that you could do this trick or use out-of-band mechanisms to
establish a kek, fine. Otherwise, I'm not sure what text you'd like.
2. Please add a paragraph to the security section area about the fact that
byte reversal may not be a good idea if the algorithm does a parity type
check over a larger than byte block. I.e. describe why the bit-wise
flip-flop was a "bad" idea.
Good idea.
3. Section 3, Note 2. Please change the text from "can occur in any of
the" to "can occur with any of the". The attribute cannot occur inside of
any ReceipientInfo object as it is an unathenticated attribute.
Fine.
4. Section 3. id-reck-attrs has a TBD.
Yes. Russ?
5. Section 3. What is the default value of CEKMaxDecrypts if it is not
present.
Given that its a hint, that's implementation specific and so there's no
generic default. If folks wanted one, I'd go with 10, but I think we can
omit this.
6. Section 4. First, the CE algorithm and the KE algorithm are never "the
same" in some sense. id-alg-CMS3DESwrap and des-ede3-cbc are different in a
number of significant ways. Please change the text. I would suggest
something along "If the CE algorithm and KE algorithm use the same key
material...". I have problems with even this because of the question of a
CEK of 128-bit RC2 and a KEK of 40-bit RC2 in which case it is not clear
that this is the algorithm one should be using.
No problem adding text clarifying what "same" means here. How about:
"Note: In some sense, the CEK and KEK algorithms are never the "same",
e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However, for the
purposes of this specification, all we care about is that the algorithms
use the same format and size of keying material (see also security
considerations) and that they do not differ significantly in terms
of the resulting cryptographic "strength". In that sense the two
algorithms in the example above are the "same.""
The best overall approach might be to say that if the KEK is A and the CEK
is B then you use the byte-reveral method and just the list ones that
"match" in impedance.
I'd really rather not be listing pairs of algorithms in this document.
Would the addition of the text above be sufficient?
7. Remove appendix B.
Nope:-) Actually, I think these are very useful and the RFC editor seems
happy to reomve 'em.
8. Appendix A. Missing module number
Yep. Russ?
9. Appendix A. --<<IMPLICIT??>>-- should be removed or fixed
Well, which do you prefer in this case? I'm not sure.
10. id-reck-attrs is TDB
Yep.
12. Please add comments to the effect of what goes into each of the fields
and that there is an association between the pairs as OID attribute value.
Huh? You mean in the ASN.1 module? I think in a 7 page i-d, the reader
is expected to read more than just the ASN.1 module.
Stephen.
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:stephen(_dot_)farrell(_at_)baltimore(_dot_)ie
Ireland http://www.baltimore.com