would like to see is a discussion of when a protocal should use the proposed
method rather than one of the above suggested methods.
Ok - how about adding this to section 2: "There are other ways that could
be envisaged to establish the required symmetric keying material, e.g.
by leveraging a group keying scheme or by defining a content type
that contains a KEK value. Although this scheme is much simpler than generic
group key management, if an implementation already supports group key
management then this scheme doesn't add value. This scheme is also
suitable for inclusion in CMS libraries (though the addition of new state
might be a problem for some implementations), which can offer some
advantages over application layer (e.g. where the content includes the KEK)
Definitely needs wordsmithing, but is that the type of thing you mean?
5. Section 3. What is the default value of CEKMaxDecrypts
if it is not
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
One is fine then. Will add.
6. Section 4. First, the CE algorithm and the KE
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?
Fair point. Will add that.
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.
Phew! (I just hate tags:-)
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
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
Well...I agree its somewhat useful, but I also think its marginal and in the
worst case misleading (too abbreviated). However, since its not worth getting
hung up about this, I'll add comments like those in CMS.
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