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
Robert R. Jueneman.vcf
Description: Vcard