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

[Stephen Farrell <[e-mail]>]

Hi Jim,

[...]
> 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.

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)
schemes."

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
> > > present.

> 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.

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
> > attribute value.
[...]
> 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.

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.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com