RE: Re: Issues with S/MIME Message Specification

[bartley.o'[e-mail]]

I was under the impression that the purpose of defining a standard was to 
create a specification which people could follow, independently, to produce 
interoperable products. Creating a world-wide standard which significant 
portions of the world are unable to comply with is pointless. We are likely to 
end up, unofficially, with S/Mime(Strong) and S/Mime(Weak), people are just as 
likely to be frightened by incompatible varying implementations.

The whole idea of MUST is to produce a minimum level of interoperability which 
EVERYONE can adhere to. SHOULD is there to enable those who have the 
time/money/inclination/authorisation to achieve higher levels of 
interoperability and security, with MAY specifying the very highest levels.

I believe Enzo is correct in his statement that minimum levels of compliance 
cannot be specified as SHOULD. However, the strongest level of encryption 
available, 3DES, ought not to be listed in the minimum compliance requirements.

Bob Jueneman's objection(since withdrawn) to the trade secret RC2 algorithm is 
eminently reasonable. The IETF's refusal to use proprietary or restricted 
material is equally sensible. The problem we have is that the US government 
maintains a "proprietary" claim over 3DES in the form of export restrictions, 
as do many other governments regarding encryption algorithms. Until we have all 
lobbied our respective governments to remove these restrictions we MUST operate 
sensibly within them. 

3DES ought to be listed as SHOULD and those who can write/export 3DES SHOULD 
and those who can't....can't.

I believe that section 2.7.1 provides adequate recommendation and controls to 
enable the strongest available algorithm to be selected. There is a requirement 
for approval to use weak encryption prior to sending each weakly encrypted 
message, so there is little chance of one sending insecure messages by accident.

Bartley O'Malley
UK

-----Original Message-----
From: owner-ietf-smime(a)imc.org 
Sent: Wednesday, May 19, 1999 12:26 PM
To: ietf-smime(a)imc.org; aferguso(a)enternet.com.au
Cc: em(a)who.net; cryptography(a)c2.net
Subject: Re: Issues with S/MIME Message Specification

I disagree totally with the idea of making strong encryption optional.
First of all, one cannot use SHOULD on matters of minimal compliance.
Second, a standard cannot be defined conditionally to the local laws: at
most, the development process of actual products, and their sales, may have
to depend on them.
Third, allowing exportable (i.e., totally useless) encryption in algorithms
and protocols required for minimal compliance will result in nobody buying
products based on that standard, opting instead for, e.g., OpenPGP, or even
de-facto standards. The right ways to avoid export restriction are:
a) Lobby your governments, letting them know that such stupid laws will
result in job losses and hamper the development of e-commerce, and have the
laws changed. This often works: France is a recent example.
b) If a) fails, develop products in places where those laws do not apply.

Deceiving the public with products which are defined "secure" (what does the
"S" in "S/MIME" stand for?), and are not, is not only unethical, but
ultimately will harm the sales and the vendor's bottom line. IETF should
steer clear from endorsing such ill-advised practices.

Enzo


----- Original Message -----
From: Andrew Ferguson <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, May 19, 1999 5:47 PM
Subject: RE: Issues with S/MIME Message Specification


> 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.
>
> At 10:34 19/05/99 , Robert R. Jueneman wrote:
> >>>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
> >
> >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.
> >
> >>
> >>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.
> >>
> >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
> >
> >
>
>
> ------
> Software Agencies Australia Pty Ltd
> 1 Huntingdale Road
> Burwood,
> Victoria 3125
> Australia
> ACN 078 025 813
> Tel: [phone]
> Fax: [phone]
> Mobile: [phone]
> Email: [e-mail]
> URL: www.software-aus.com.au
> Your Business Partner in Electronic and Internet Commerce
>
>

 << File: UnXhrds.txt >>