[Top] [All Lists]

RE: Issues with S/MIME Message Specification

1999-05-19 02:47:30
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

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.



Software Agencies Australia Pty Ltd
1 Huntingdale Road
Victoria 3125
ACN 078 025 813 
Tel: +61-3-9808-0522
Fax: +61-3-9888-6019
Mobile: +61-41-222-3940
Email: Andrew(_dot_)Ferguson(_at_)software-aus(_dot_)com(_dot_)au
Your Business Partner in Electronic and Internet Commerce