Stephen,
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.
One simple way to do this is to use the GLKey control from the symmetric key
distribution draft. This allows for a standard way to distribute a KEK key
which could be used for a short time. Alternatively the protocal that is
using this draft could in turn define a first message that distributes the
KEK value and then uses that for some set of subsequent messages. What I
would like to see is a discussion of when a protocal should use the proposed
method rather than one of the above suggested methods.
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.
The two values that I though of immeadately are either 1 or inifinite. Of
the two I would probably go with 1 and insist that you do continous
chaining.
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?
I would like to see the phrase "using the same underlying cryptographic
operation" added somehow. I could argue that MARS and AES use the same
format and size of keying material and they are of similar strength. Do you
want to be using the byte swapping this case as well?
9. Appendix A. --<<IMPLICIT??>>-- should be removed or fixed
Well, which do you prefer in this case? I'm not sure.
For your module it makes absolute no difference as there is no tagging
contained in the module.
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.
I don't expect that the ASN.1 module will stay with the i-d. I often take
out the modules and save them on their own. It is useful to be able to scan
the ASN when I am decoding messages without having to resort to reading the
entire draft.
Stephen.
jim