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

From: "Jim Schaad" <[email-masked]>
Date: Sun, 25 Feb 2001 15:16:18 -0800

First - I assume that the last call is not going to be closed on the 26th
because a new version of the document needs to be issued with some fixes in
it.

Changes that I think need to be addressed before advancement.

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.

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.

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.

4.  Section 3.  id-reck-attrs has a TBD.

5.  Section 3.  What is the default value of CEKMaxDecrypts if it is not
present.

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.

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.

7.  Remove appendix B.

8.  Appendix A. Missing module number

9.  Appendix A.  --<<IMPLICIT??>>-- should be removed or fixed

10.  id-reck-attrs is TDB

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.

jim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Feb 2001 09:48:59 +0000

Hi Jim,

Thanks for reviewing 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.

> flip-flop was a "bad" idea.

Good idea.

> 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

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

> is B then you use the byte-reveral method and just the list ones that

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.

> 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:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 26 Feb 2001 15:32:24 -0800

Stephen,

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

> generic default. If folks wanted one, I'd go with 10, but I

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.

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

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

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

jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Feb 2001 11:21:54 +0000

Hi Jim,

[...]
> What I

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?

> 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
[...]
> want to be using the byte swapping this case as well?

Fair point. Will add that.

> For your module it makes absolute no difference as there is no tagging

Phew! (I just hate tags:-)

> > > and that there is an association between the pairs as OID
[...]
> 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.

Stephen.