-----Original Message-----
On Behalf Of Luther Martin [martin(_at_)voltage(_dot_)com]
The US Department of Defense has issued client certs certs to
roughly 5 million users, and they still can't be used for much.
If the DOD ever gets the $5 billion or so that they've asked for
to PKI-enable applications, these certs may be put to use, but
that funding doesn't seem to be coming any time soon.
They can be used for signing (as with this message), and can be
used to access those services (such as Defense Knowledge Online)
that have been PK enabled. Authenticated access to services is
a critical issue for DoD, and it will get funded.
- You cannot send an encrypted e-mail to the IRS and you
probably never will
You want to bet? If IRS's in other countries can do it, why wouldn't
the IRS in the US do it in the near or not so near future?
I don't see this happening any time soon. The dead horse of usability
is now probably sufficiently beaten by my comments above, so I
won't further defile the body.
I agree that this won't happen anytime soon. TLS server certs are
widely deployed now, unlike client certs. S/MIME encryption
to server certs could be made usable, but what is the business
case? Encryption might as well be done at the transport layer,
with data at rest protection (keeping those credit card numbers
on laptops secret) being a local matter. There is a far stronger
case to be made for S/MIME signing than for S/MIME encryption.
Instead of issuing certs to people, it might actually be cheaper
for the IRS to use its FedEx account number as a sort of public
key that lets people get documents to them in a secure way,
just without using the S/MIME standard.
Huh??? You've totally lost me there. www.irs.gov already has
a real public key, and S/MIME applications already exist. Can you
explain the cryptographic mechanism for turning a public value
(such as a FedEx account #) into a "public key" of some sort
usable for encryption without involving a third party (e.g. a
CA or IBE key server - I see your email address is Voltage)?
How in the world would it be cheaper to develop a new
cryptographic mechanism, propose and standardize the data
formats and protocols to support it, develop and deploy
new client and server applications, and stand up new third
party authentication servers? What makes message encryption
using S/MIME any more expensive than message encryption using
any possible replacement, including IBE?
- e-mail encryption is incompatible with many organizations'
internal policies
What are you referring to? We see the opposite being true in
every company we talk to.
Most businesses like to filter e-mail for spam and other annoyances,
which is fairly difficult to do with encrypted e-mail.
Anders used to talk quite a bit about domain encryption, and
RFC 3183, though experimental, was completed five years ago.
There's nothing intrinsically difficult about filtering
encrypted email. But with online services becoming ubiquitous
on the Internet, the need for end-to-end message encryption
in a store-and-forward environment is shrinking. For many
applications it is feasible to use TLS end-to-end instead.
smime.p7s
Description: S/MIME cryptographic signature