Robert Jueneman writes:
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'm not here as a representative of my company, but I suspect we'd take
half a market rather than none, and we'd be lobbying our government
continuously to do something against this blatant crippling of Irish
software.
As for an actual employee of an actual US company, Ned Freed put it
better than I could:
http://www.imc.org/ietf-smime/mail-archive/msg00169.html
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"?
MUST is from RFC 2119, and there's no wriggle-room there ("This word, or
the terms "REQUIRED" or "SHALL", mean that the definition is an absolute
requirement of the specification"). There can't be, in fairness. It's an
interoperability thing.
All S/MIME has to do is produce something that's secure and
interoperable. If there's an option that's secure and interoperable and
can be exported by anyone from the US, it hasn't been presented, as
far as I know.
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.
From listening too much to our marketing people, I get the impression
that US vendors that can't export strong cryptography are doing just
that in those markets. But I'd rather hear something from one of the US
companies. Jim? Blake? Someone from Netscape (who is someone from
Netscape these days)?
Also, it cuts both ways. If the specs have a MUST for weak crypto (and
they have to have a MUST, for interoperability), then people out here
will get requirements that they produce S/MIME that cannot default to
weak crypto, and they'll break interoperability. Not that any of this is
the business of the IETF. The IETF's business is making the best standards.
Regards,
Bob
Andrew.