Subject: Protocol Action: Cryptographic Message Syntax to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 17 May 1999 07:26:04 -0400

The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:

 o Cryptographic Message Syntax <draft-ietf-smime-cms-13.txt> 
 o Diffie-Hellman Key Agreement Method <draft-ietf-smime-x942-07.txt> 
 o S/MIME Version 3 Certificate Handling <draft-ietf-smime-cert-08.txt>
 o S/MIME Version 3 Message Specification <draft-ietf-smime-msg-08.txt>
 o Enhanced Security Services for S/MIME <draft-ietf-smime-ess-12.txt>

These documents are the product of the S/MIME Mail Security Working Group.
The IESG contact persons are Jeffrey Schiller and Marcus Leech.

Technical Summary
 
These documents describe Version 3 of S/MIME (Secure/Multipurpose
Internet Mail Extensions). S/MIME provides for the secure
communication of MIME Objects, providing Authentication, Integrity and
Confidentiality protection. It can be used wherever MIME is used, as
it is fully conformant with the general MIME specifications. The
documents here provide for the basic message syntax and semantics as
well as the certificate and key management infrastructure
required. This work is coordinated and builds upon the work of the
IETF X.509 Public Key Infrastructure Working Group (PKIX).

In addition to the basic security services mentioned above, several
optional services are described. These include signed receipt
handling, security labeling of objects, secure mailing lists and
signing certificates.

Working Group Summary

The working group came to consensus on the work described here. A lot
of people contributed thoughtful, useful and constructive comments
during the review periods which resulted in further improvements
reflected in these documents.

Jeffrey I. Schiller reviewed the specification for IESG.

---

From: "Robert R. Jueneman" <[email-masked]>
Date: Tue, 18 May 1999 12:34:32 -0600

I sincerely regret not having had sufficient time to review the S/MIME v3
specs in detail during last call and prior to their moving to Proposed
Standard, but I believe that there are several changes that absolutely
must be made before they can progress to final Standard.

Regarding the S/MIME Version 3 Message Specification,
draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs
regarding specific cryptographic algorithms should be removed from this
document, and contained only in the Cryptographic Message Syntax document.
I can see no reason at all why such things should be specified twice -- it
just makes conformance checking all that much more difficult.  An example
of this kind of difficulty is para 2.2 of the S/MIME Message
Specification, which says that sending and receiving agents SHOULD support
rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says
that CMS implementations "may" support RSA.  Neither mentions RSA with
OAEP.

This affects section 2.1, 2.2, and 2.3, and most emphatically section 2.7,
"ContentEncryption AlgorithmIdentifier", and 2.7.1.3 "Rule 3, Unknown
Capabilities, Unknown Version of S/MIME."

Without getting into international politics, at the present time
triple-DES is not exportable from the US, at the very least, and may very
well not be importable into some other countries.  Specifying that S/MIME
agents MUST implement triple-DES therefore presents a vendor with Hobson's
choice -- they can either chose not to be compliant with the RFC, or they
can chose not to export their product.  Unfortunately, that is no choice
at all -- any sane US vendor will choose not to be compliant with the RFC,
rather than lose perhaps 50% of their market.  The only purpose such a
red-flag-in-front-of-the-bull statement serves, therefore, is a political
one, and one that will merely lower the credibility of the IETF and the
IESG in the vendor and business community.  At most the requirement should
be SHOULD.

The second part of 2.7 specifies that receiving agents SHOULD support
RC2/40 "or a compatible algorithm at a key size of 40 bits..." This
recommendation suffers from two major problems, in my view. First, it is
LESS secure than 56-bit DES, which is now acceptable world-wide (with
perhaps one or two minor exceptions -- not quite clear) for data
encryption.  And second, it is a proprietary, trade-secret algorithm.  Not
only is that contrary to the general direction of the IETF in not
mandating proprietary algorithms, but the fact that it is a trade secret
(not withstanding the fact that it has been reverse engineered) means that
there has not been adequate attention paid to its security in the academic
cryptanalytic community.  RC2 of any size may well be worth considering
for support, and might deserve RECOMMENDED status, but that should be up
to the vendor.  If RC2 is required for backwards compatibility with S/MIME
v2, then a paragraph noting that fact would be appropriate, as was
provided as the last paragraph under 2.3 ("Note that S/MIME v2 clients are
only capable of decrypting content encryption keys using the rsaEncryption
algorithm.").

(I am taking this position with no lack of respect for Ron Rivest, whom I
consider a very able cryptographer.  But I would take that position if God
Herself had invented but not published some particular algorithm.)

With respect to 2.7.1.3, there are two problems. First, it mandates
triple-DES, which very well may not be available at to the recipient, and
secondly, it recommends as a fall back position the use of the
trade-secret RC2/40.  Both statements should be removed. The CMS
specification should then develop a list of algorithms in rough order of
strength, to be used for such negotiations as required.

Finally, somewhere in these documents there is a statement regarding the
advisability of including the content encryption key encrypted in the
originator's public key, but despite rereading the documents multiple
times I can't find that text again.  As I recall, the text said that this
SHOULD be done.  I would argue that this should be changed to MUST, for I
can't imagine a situation where the originator of an encrypted message
would not want to be able to read his own message, for example in an
outgoing or Sent-Mail queue. He might need to be able to decrypted, and
even retract it in order to resend it with modifications.  It would not be
reasonable to rely on the originator to bcc herself to gain this
capability -- it ought to be required by the spec.

I will be addressing my concerns with the CMS specification in a
subsequent message.

Bob

---------------------------
Robert R. Jueneman
Novell, Inc.

(See digital signature DISCLAIMER in attached vCard)

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of The IESG
>Sent: Monday, May 17, 1999 5:26 AM
>To: IETF-Announce: ;
>Cc: RFC Editor; Internet Architecture Board; [email-masked]
>Subject: Protocol Action: Cryptographic Message Syntax to Proposed
>Standard
>
>
>
>

---

From: EKR <[email-masked]>
Date: 18 May 1999 13:02:52 -0700

> that CMS implementations "may" support RSA.  Neither mentions RSA with
CMS and S/MIME MSG intentionally have different requirements.
In order to preserve backwards compatibility with S/MIMEv2,
implementations SHOULD implement RSA. CMS implementations that
do not need to be used in the S/MIME context may very well
have no need to use RSA.

> encryption.
The purpose of this is once again for compatability with S/MIME v2 
which required RC2. 

>  And second, it is a proprietary, trade-secret algorithm. 
This statement is incorrect. See RFC-2268:

2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest.
     January 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL)

> capability -- it ought to be required by the spec.
I disagree. Firstly, it's entirely possible that the originator
does not have a public key suitable for data encryption -- he
might have a signature only key. Secondly, encrypted content keys
take up a not-insignificant amount of space in the message. Mandating
this serves no interoperability requirement and therefore 
it's inappropriate.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 18 May 1999 13:13:38 -0700

>must be made before they can progress to final Standard.

The issues you bring up here were not changed in the last call drafts. The 
location of the requirements for algorithms has been the same for over a 
year. I believe that it is inappropriate for you to object to the RFC 
Editor at this very late date.

The step after they become Proposed Standards is to possibly become Draft 
Standards, not "final Standard". There will be plenty of time to discuss 
your issues in the Working Group in the interim.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Robert R. Jueneman" <[email-masked]>
Date: Tue, 18 May 1999 16:26:42 -0600

Eric,

Thanks for your comments.  I hadn't considered the possible difference in scope between the S/MIME Message Specification and the CMS, but I can see that CMS might have broader applicability, and hence, differing requirements.

I was also unaware of the fact that an information RFC had been published on RC2, and withdraw my comments on that accordingly.

With respect to the issue of bcc'ing the originator on an encrypted message, although I suppose it is possible that the originator doesn't have a public encryption key, this seems mildly unlikely, so I am more inclined to agree with William Whyte's comment.

I wish I could find where I read that statement -- I thought it was in one of the RFC's, but I can't find it.

Regards,

Bob

>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, May 18, 1999 2:03 PM
>To: [email-masked]
>Cc: The IESG; RFC Editor; [email-masked]
>Subject: Re: Issues with S/MIME Message Specification
>
>

---

From: Andrew Farrell <[email-masked]>
Date: Wed, 19 May 1999 01:05:47 +0100

>Thanks for your comments.  I hadn't considered the possible difference 
>in scope between the S/MIME Message Specification and the CMS, but I can 
>see that CMS might have broader applicability, and hence, differing 
>requirements.

This is also the reason why there are, on close examination, no MUSTs
or SHOULDs in CMS. 

>With respect to the issue of bcc'ing the originator on an encrypted
>message, although I suppose it is possible that the originator doesn't
>have a public encryption key, this seems mildly unlikely, so I am more
>inclined to agree with William Whyte's comment.

I'm not sure that the My Esteemed Colleague's comment was anything
more than a point of information. There will be situations when an
application should include an originator key, but there are also counter
examples. Locking a MUST into the standard is unnecessary, particularly
since there's no compelling interoperability or security issue.

>I wish I could find where I read that statement -- I thought it was in =
>one of the RFC's, but I can't find it.

draft-ietf-smime-msg-08.txt, section 3.3

Also, it should be noted that switching from MUST RC4 to MUST tripleDES
was the very first thing the ietf-smime group did, back 2 years ago.
There was a lot of discussion back then, all of it available on the IMC
mail archive. Not intended as a brush-off: there was a lot of relevant
debate.

>Bob

Andrew.

---

From: "Robert R. Jueneman" <[email-masked]>
Date: Tue, 18 May 1999 18:34:01 -0600

>draft-ietf-smime-msg-08.txt, section 3.3

Thanks. I knew I had read it, but couldn't find it.

Now that I see the exact text once again, and given the apparent 
request by some to NOT keep a copy, I can live with SHOULD.

>mail archive. Not intended as a brush-off: there was a lot of relevant
I can certainly understand preferring triple-DES vs. RC4, but I'm still not 
thrilled about having a firm specification that it is illegal for me to comply with 
if I hope to export the product.  I can fully understand that perhaps you 
might not share my concern on this point--neither do the Canadians, the
Australians, or others!  :-)

But what would your position be if the situation were reversed, or if, for 
example, you could not export such a product to the US, and you might 
face losing half of your market as a result?

I confess I haven't looked up the precise definition of MUST. Is there 
perhaps some face saving wriggle-room that says something like
"except where prohibited by law or regulations"?

Not being compliant with the RFC doesn't bother me all that much--
there aren't any IETF police, and procurements that require 
compatibility just won't get it, except for US/Canada domestic and 
certain industry sectors outside the US.  

What concerns me more is the assumption that because the 
standard says MUST, there is a presumption that it WILL
actually be so, and that interoperability decisions about 
what kind of algorithms can be used can assume this as a default.
T'ain't so, unfortunately, unless all of the US vendors roll over and 
play dead in the European and Asian markets. And that isn't 
going to happen.

Regards,

Bob

---

From: Andrew Ferguson <[email-masked]>
Date: Wed, 19 May 1999 19:45:17 +1000

Andrew, Robert, All,
As a watcher, but not up to now an active participant in this debate on the
matter of  Issues with the S/MIME Message specification, I believe it
should say SHOULD (definitly not MUST) and perhaps to be precise refer to
the newly ratified Wassenaar agreement,  eg : "except where prohibited
under the Wassenaar Agreement" which will cover export and import into and
from various countries. This will in effect provide a neat get out clause
covering both issues. The reality as Bob points out below we Aussies are
not necessarily worried about the US Export laws, but of course Australia
now exports our own crypto developed products so we would also affected by
the statement MUST.

Anyway thats my contribution.

>play dead in the European and Asian markets. And that isn't 

------
Software Agencies Australia Pty Ltd
1 Huntingdale Road
Burwood,
Victoria 3125
Australia
ACN 078 025 813 
Tel: +61-3-9808-0522
Fax: +61-3-9888-6019
Mobile: +61-41-222-3940
Email: [email-masked]
URL: www.software-aus.com.au
Your Business Partner in Electronic and Internet Commerce

---

From: Andrew Farrell <[email-masked]>
Date: Wed, 19 May 1999 12:34:42 +0100

>I can certainly understand preferring triple-DES vs. RC4, but I'm still 
>not thrilled about having a firm specification that it is illegal for
>me to comply with if I hope to export the product.  I can fully
>understand that perhaps you might not share my concern on this
>point--neither do the Canadians, the Australians, or others!  :-)

>But what would your position be if the situation were reversed, or if, 
>for example, you could not export such a product to the US, and you
>might face losing half of your market as a result?

I'm not here as a representative of my company, but I suspect we'd take
half a market rather than none, and we'd be lobbying our government
continuously to do something against this blatant crippling of Irish
software.

As for an actual employee of an actual US company, Ned Freed put it
better than I could:

http://www.imc.org/ietf-smime/mail-archive/msg00169.html

>"except where prohibited by law or regulations"?

MUST is from RFC 2119, and there's no wriggle-room there ("This word, or
the terms "REQUIRED" or "SHALL", mean that the definition is an absolute
requirement of the specification"). There can't be, in fairness. It's an
interoperability thing.

All S/MIME has to do is produce something that's secure and
interoperable. If there's an option that's secure and interoperable and
can be exported by anyone from the US, it hasn't been presented, as
far as I know.

>play dead in the European and Asian markets. And that isn't

From listening too much to our marketing people, I get the impression
that US vendors that can't export strong cryptography are doing just
that in those markets. But I'd rather hear something from one of the US
companies. Jim? Blake? Someone from Netscape (who is someone from
Netscape these days)?

Also, it cuts both ways. If the specs have a MUST for weak crypto (and
they have to have a MUST, for interoperability), then people out here
will get requirements that they produce S/MIME that cannot default to
weak crypto, and they'll break interoperability. Not that any of this is
the business of the IETF. The IETF's business is making the best standards.

Andrew.

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 May 1999 10:45:37 -0400

Bob:

In CMS Section 12.3.2, RSA Key Management is a "should" implement
algorithm.  As a result of an editorial error, in CMS Section 12.2, RSA
Signature is a "may" implement algorithm.  I thought that they had the same
"should" status.  This would be consistent with the MSG document.

We went through great pains to include support many, many algorithms in
CMS.  The  "must" implement algorithms to provide a set of interoperable
strong algorithms.  The "should" implement algorithms provide backward
compatibility with S/MIMEv2.  Any other algorithm is considered a "may"
implement algorithm. RSA with OAEP falls into this "may" implement category.

The IETF consistently includes strong algorithms in standards.  If you wish
to discuss this policy, please discuss it in a broader context (not just
S/MIME) with the IETF Security Area Directors (Jeff Schiller and Marcus
Leech).  I have CCed them on this e-mail message, so you have their
addresses.  I do not consider this an approprate topic for the S/MIME mail
list.

I wish you had raised this inconsistency during CMS and MSG Last Call.  The
IESG has approved these documents.  I hope you will raise this topic again
when the documents are considered for Draft Standard status.

Russ
  S/MIME WG Chair  &
  CMS Document Editor