-----Original Message----- On Behalf Of Luther Martin [martin@xxxxxxxxxxx] > 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature