Hello!!? Anybody home?!?!
Sorry for the sarcasm, but I thought I had made my request explict. Let me
try again.
We are discussing a protocol here. It is defined in a spec. The spec is
publicly available.
Is there something wrong with the spec? Does it force weak cryptography?
The reason the spec has a 40-bit component is that a competing protocol
that doesn't have a 40-bit component has had very little implementation in
the years that it has been out. There may be other reasons for this, but
what I've heard from US implementors has been that they couldn't implement
it without a weak cryptography component, and what I've heard from the one
international developer I talked to was that they weren't going to bother
with it unless it was clear that US companies would.
Thus, there is a desire for a second protocol that might get a bit more
implemenentation. If there was wide implementation of the existing protocol
this protocol would be worse than useless, it would be destructive.
However, the opposite is true. It's mid-1997, and less than 1% of Internet
email users have good security or authentication.
Let's all work together on that Bad Situation, shall we?
The politics behind the lack of implementation for the other spec do *not*
matter; the viability of the current spec *does*. If the current spec
requires weak cryptography, we don't want it. Period. If the current spec
handles the weak cryptography in a fashion that allows people who don't
want to touch weak cryptography to still work with the spec, then it is
good.
Keith, Lindsay, and yes, even Blake: get back on topic. There is work to be
done here. Arguing about what's best for US industry, why US laws are bad,
and so on, IS A WASTE OF OUR TIME HERE. Looking carefully at the spec and
making sure it does not mandate weak cryptography is part of the work at
hand.
(And, yes, there are still many other issues on the open issues list.)
--Paul E. Hoffman, Director
--Internet Mail Consortium