Subject: RE: Comments on MSG spec

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 20 Nov 1998 15:44:34 -0800

> -----Original Message-----
> From: Al Arsenault [mailto:[email-masked]]
> Sent: Friday, November 20, 1998 8:22 AM
> To: [email-masked]
> Subject: Comments on MSG spec
> 
>         1.  Section 2.5.3, the first paragraph is pretty 
> rough reading. 
> Recommend that the last two sentences be changed to something like:
> This attribute tells the receiver which of the sender's 
> certificates should be
> used for encrypting the session key when the receiver later 
> wants to send an
> encrypted message to the sender.  This attribute simplifies 
> interoperability
> among clients that use separate keys for signing and encryption.

Agree.

>         2.  Section 2.5.3, last paragraph:  Second sentence 
> (the one in
> parentheses):  change "to" to "too".  Third sentence, change 
> "senders" to
> "sender's".

Agree.

>         3.  Section 2.6, first sentence:  Is the reference to 
> [DES] dangling? 
> It would seem that one reference to tripleDES would be sufficient.

Not dangling -- [DES] tells you how to implement DES, [3DES] tells you how
to implement triple-DES, but not DES.

By the way, I think that the 3DES reference sucks (a 1979 IEEE Spectrum
article?).  Any suggestions?

>         4. Section 2.6, second sentence:  This is rough 
> wording.  What do you
> mena by "RC2 ... or a compatible algorithm"?  Which 
> algorithms are "compatible"
> with RC2?

I believe that the theory here is that RC2 is or was a trademark of RSADSI,
and so use of that trademark (that little (r) in the title of RFC2268)
seemed to indicate that "if you had another algorithm with a different name
that behaved exactly the same way, you'd be free and clear from any
potential IP concerns using RC2 in box copy, etc."

>         5.  Section 2.6.3 is essentially repeated in the Security
> Considerations
> section.  It's better there, anyway; I recommend deleting 2.6.3.

I agree with Paul's comments here.  Can't complain too much about this.

> 
>         6.  Section 3.1, last paragraph before 3.1.1:  this 
> paragraph is out of
> place.  It belongs in Section 4, if it's not already covered there.

I agree with Paul's comments here.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

---

From: Al Arsenault <[email-masked]>
Date: Mon, 23 Nov 1998 08:00:45 -0500

At 03:44 PM 11/20/98 -0800, Blake Ramsdell wrote:
> <snip>

The IEEE Spectrum article is usually cited to give Tuchman credit for the
work; I think it's the first published description of 3DES.  (Schneier uses
that reference, too.) However, if you're looking for something better, Ford
& Baum cite ANSI X9.52, "Triple Data Encryption Algorithm Modes of
Operation", 1997.  I had thought that X9.17 covered it, too, but I can't
find my copy of X9.17 at this moment.  The ANSI refs are probably better
than Tuchman, in that they give you a single place that describes both DES
and 3DES.

>potential IP concerns using RC2 in box copy, etc."

Now that I remember what this is all about, I'd like to agree with Paul's
suggestion:  kill the "or a compatible algorithm" stuff.

<snip>

>I agree with Paul's comments here.

The problem I had was that 3.1 talks about preparing a message.  Three
steps are listed (preparing the MIME entity, canonicalization, applying
transfer encoding), none of which deals with applying security services.
Out of nowhere comes a paragraph that says a receiving agent first
processes the security services, then ...  It just didn't seem to flow.
I'm not willing to argue about it any more, though; it's not that big a deal.

					Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.