RE: Issues with S/MIME Message Specification

["Robert R. Jueneman" <[e-mail]>]

>>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