[Top] [All Lists]

RE: Issues with S/MIME Message Specification

1999-05-18 17:34:38
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 
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.



Attachment: Robert R. Jueneman.vcf
Description: Vcard