Subject: Re: Goal for S/MIME 2007?

From: Christine Karman <[email-masked]>
Date: Sun, 21 Jan 2007 11:07:49 -0800

>----- Original Message -----
>From: <mailto:[email-masked]>Anders Rundgren
>To: <mailto:[email-masked]>[email-masked]
>Sent: Saturday, December 23, 2006 10:36
>Subject: Goal for S/MIME 2007?
>
>- Client certificates are [still] uncommon

You think so? In some countries in Europe, everyone has one through a 
chip in their identity card. In some countries, every medical 
professional has several of them. Some Fortune-100 companies provide 
them to every employee.

>- Encryption at the desktop by consumers does not work

What makes you think so?

>- Security administrators want central policy handling

They already have that because most commercial products in this area 
provide them with central policy management.

>- Trusted third-parties is the norm (from your employer to Google)
>- 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?

>- 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.

>- Security should be transparent, default, and non-intrusive

You're right.

Because of SOX, most companies want to secure their email. They want 
filtering, encryption, signing. The issue is, will they use S/MIME or 
will they use some non-standard algorithm. In Europe, it's mostly 
S/MIME. So I don't see your point. S/MIME will be the dominant 
algorithm for encrypting and signing of email, both in the US and elsewhere.
Do you sign your email with your trusted certificate, assuming you 
have several?

Christine

-- 
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

---

From: "Luther Martin" <[email-masked]>
Date: Sun, 21 Jan 2007 20:29:51 -0800

>professional has several of them. Some Fortune-100 companies provide

I really don't see client certificates being used much. My Amex Blue card has a cert on it. Maybe even more that one. But I can do exactly two things with these certs: Jack and squat. So the existence of certs isn't necessarily an indicator of their existence in a useful way.
 
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. The US government has spent over $1 billion on PKI so far, and has very little to show for it. I understand the political need to keep PKI engineers at government contractors employed, but $1 billion really seems like a lot of money. 
 
The cost of using client certs can be painfully high. One study that I read estimated that the TCO for using a cert for e-mail was $816 per user per year. Ouch. That kind of cost is usually a bit tough to justify. Maybe that's why certs are really not that popular, at least as we're probably talking about here. If you use Windows, you may be using a cert without even knowing it, for example, but I don't think that the intent of the original comments.

>What makes you think so?
 
I believe this one also. Studies of the US DOD PKI have shown that the vast majority of key recovery is done because of lost or forgotten passwords. Without this capability, the home user is a bit stuck. With it, you've got significant support costs. 
 
Usability of encryption has gotten better but it's still not very good. The famous "Why Johnny Can't Encrypt" was followed by the more recent (2006, IIRC) "Why Johnny Still Can't Encrypt," that showed that usability still has a long way to go. Poor usability equals high support costs, which in turn means no business case to use the technology. 

>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. 
 
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. 

>What are you referring to? We see the opposite being true in every

Most businesses like to filter e-mail for spam and other annoyances, which is fairly difficult to do with encrypted e-mail. That's a fairly common request.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 22 Jan 2007 13:00:29 -0500

-----Original Message-----
On Behalf Of Luther Martin [[email-masked]]

> 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.

> 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?

>> 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.

---

From: Christine Karman <[email-masked]>
Date: Mon, 22 Jan 2007 18:25:23 -0800

At 10:00 AM 1/22/2007, Kemp, David P. wrote:

>widely deployed now, unlike client certs.

TLS does not provide the level of protection that server-to-server 
S/MIME tunneling does. E.g, what happens if a server that uses TLS is 
temporarily unavailable and the backup server (or the backup thereof) 
doesn't have TLS? Will your mail server store all messages until a 
TLS server is available? Do system administrators manually check 
validity of all TLS certs, like when one expires and a new one is 
installed? I doubt it.

>S/MIME encryption

I couldn't agree more. That's what we see in the market. However, 
more wide spread use of S/MIME signing creates a business case for 
S/MIME encryption, as more and more certs are out there to be used.

dagdag
Christine

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 25 Jan 2007 22:30:49 +0100

In theory S/MIME could be one "cure" against spam, viruses and phishing.

There are at least two things making this stay as "theory".

1.
There is no S/MIME trust structure that works except rather locally,
effectively making every person on the net a "PKI trust administrator".
Although the DoD have a solution ( http://www.certipath.com/services.htm ),
few other organizations can spend huge amounts of tax-payer money just
to prove that "it can be done", but are rather evaluating other options.

2.
The unavailability of a cheap, mobile, secure and fully standardized
container makes the certificate requirement a much too high bar.  That
not even the financial sector have managed to deploy such schemes to
more than 1-2% in spite of 10+ years of on-line banking is in my opinion
good enough as a proof.  The virtual explosion of Web-mail and mobile
phone mail, actually makes the S/MIME-card-everywhere-vision
more distant than ever.  Well, the DoD have no problems [of course], 
http://www.karbonsystems.com/BlackBerry-SMIME-CAC-products_detail-83.html
but who else would buy $200+ card-readers?

It might be interesting knowing that some governments have indeed
removed S/MIME from their C2G (Citizen-to-Government) PKI
schemes since they have noted that the web is a more powerful way
of delivering services as well as offering encryption for free.

Regarding the failed DOMSEC experimental RFC, I believe that it
[partly] failed because the authors did not realize that there already was
a globally working PKI they should have hooked into; the web-server
SSL PKI.  Imagine, securing an entire e-mail domain for a measly $100-
$200 annually!  Too simple, too obvious, and too commercial I guess.

AR