RE: WG Last Call:draft-ietf-smime-rcek-01.txt

["Jim Schaad" <[e-mail]>]

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