Subject: RE: dissemination of public encryption certificates

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 11 Aug 2003 16:55:50 -0700

Hi,

	This issue is one of the main use cases for XKMS. This has
considerable support within the PKI community, VeriSign, Microsoft, RSA,
Entrust and Baltimore have been involved in writing the specification
which is in the final post last call stage in W3C.

	The (almost) final spec is to be found at 
	http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html
	http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

	There will be two further changes to the spec, one to make a
minor tweak to the schema sometime this week, the second to change the
examples to use exclusive C18N.

	An XKMS locate service may be advertised in the DNS using the
SRV record. So to send mail to [email-masked] you do an XKMS locate
to _xkms_http._tcp.example.com.
That gives you the XKMS service.

	You then do a locate for a certificate to be used with S/MIME.

		Phill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 08, 2003 10:07 PM
> To: [email-masked]
> Subject: dissemination of public encryption certificates
> 
> 
> Hi,
> 
> Since this is my first posting to this mailing list, let me introduce 
> myself :
> 
> I'm a software engineer in AOL / Netscape and one of my 
> responsibilities 
> for several years has been to maintain the open source 
> Netscape Security 
> Services (NSS) library, which is used in the Mozilla browsers, many 
> Netscape and Sun servers, and other internal products. The 
> NSS library 
> contains an implementation of S/MIME v3.
> 
> I was wondering what thoughts you may have on the following problem :
> 
> If I have a keypair and e-mail certificate, and I want to 
> send encrypted 
> e-mail to somebody knowing his e-mail address, what's a 
> systematic way 
> to obtain the recipient's encryption certificate ?
> 
> Traditionally today, signed e-mail messages typically contain the 
> signer's public encryption certificate. However that means one party 
> needs to first send a signed unencrypted, e-mail message to 
> transmit the 
> public encryption certificate before both parties can 
> exchange encrypted 
> messages.
> 
> There are also ways to find recipient certificates today 
> using corporate 
> directory servers, but users must know about them and 
> manually configure 
> them in their applications, and they are typically not widely 
> available 
> on the Internet.
> 
> I'm envisioning some standardized scheme where, by starting with the 
> recipient's email address, it would be possible to locate a public 
> directory server, then find the recipient's certificate by 
> looking it up 
> in that directory server.
> 
> My main question is : has any similar scheme been proposed ? I would 
> rather work with something that exists, but if there is nothing that 
> fits, I'm open to writing an RFC.
> 
> Also, what are the other ways that people locate recipient 
> S/MIME e-mail 
> encryption certificates ?
> 
> Thanks.
> 
> 
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 12 Aug 2003 18:31:53 +0200

Pierre,
It is good to hear somebody bring up this question which is absolutely
vital for successful deployment of encrypted mail.

Personally I don't think that neither the S/MIME WG or XKMS WG
have a solution that at least I would call "acceptable".

XKMS addresses to some extent the enterprise scenario but only
if the enterprise has their own domain and associated CA.  For
truly TTP-based certificates you are out of luck if you are looking
for automated functionality.

I believe that the mail protocol and associated applications
should be augmented with encryption certificate lookup. A
MIME X-extension that you configured in your e-mail client
would do a part of this.  I.e. each time you sent a mail, the
lookup would be transmitted as well.   Also it would be
nice to have an enhanced "mailto:" URL supporting the same
mechanism.

In summary I think that a certificate-independent configuration
of e-mail clients would be more universal than "fishing" in
domains as the user domain and issuer domain may be entirely
disjunct.

Anders

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 12, 2003 01:55
Subject: RE: dissemination of public encryption certificates

Hi,

Phill

---

From: [email-masked] (Julien Pierre)
Date: Wed, 13 Aug 2003 16:19:36 -0700

Philip,

 >         You then do a locate for a certificate to be used with S/MIME.

Thanks. This is very interesting and I will need to read more on XKMS. 
Until I do, you may be able to answer the following question : can the 
XKMS be easily delegated by the domain owner to a third party in the 
DNS, just like mail and web services usually are typically delegated 
today ? It certainly looks like it from the above, but I just want a 
confirmation.

-- 
I am the dog in dogfood

---

From: [email-masked] (Julien Pierre)
Date: Wed, 13 Aug 2003 19:29:53 -0700

Anders,

 > vital for successful deployment of encrypted mail.

I'm also glad to see interest in solving this problem.

 > for automated functionality.

Are you saying basically that this won't work for Joe User at 
randomisp.com, who wants to register with randomca.com ?
 > nice to have an enhanced "mailto:" URL supporting the same

If you send an email today, you can simply sign it and include your 
certificate in the signature. If you just sign all your mail, then all 
you always disseminate your certificate. So in what situations does this 
new MIME extension certificate lookup help ? I suppose this extension 
would be shorter than a digital signature. However it would also be much 
less secure.

The case I originally asked about is :
neither party has exchanged any e-mail yet, but they know each other's 
e-mail address. They want to communicate securely. How do they avoid or 
bypass the initial insecure e-mail exchange ?

 > domains as the user domain and issuer domain may be entirely

"Fishing" in domains as you say would be independent of e-mail client 
configuration for the most part (it could just be turned on or off).

You correctly point out that in most cases the user's domain and cert 
issuer domain are disjoint. This is especially true of e-mail users 
whose ISP isn't a CA (99.9% of them right now). The only solution for 
these users is some sort of universal registration service. This implies 
the existence of some sort of free worldwide directory service (LDAP) 
that would resolve e-mail addresses to certificates ... And clients 
would need to be (automatically?) configured to do look ups in it.

-- 
I am the dog in dogfood

---

From: Steve Hole <[email-masked]>
Date: Thu, 14 Aug 2003 10:30:28 -0700

Well, for the first time in a long time my interest is up on this 
list :-).    What a wonderful topic!   General purpose use of 
S/MIME by the masses on the Internet.   Why hasn't it happened and what 
can we do about it.

Before you read on, be assured that it is the large scale use of S/MIME 
that the following diatribe is focused on.

> would be shorter than a digital signature. However it would also be much 

This highlights one of the key issues.   It is easy enough to exchange 
keys simply by sending a signed message, but there are some significant 
barriers:

1.  What if your encryption key is separate from your signing key.   This 
is not only common but considered good security practice.   How does one 
go about exchanging/discovering the encryption key for the new party you 
want to exchange mail with.

2.  Timeliness of the key exchange.   The problem with mutual signing 
exchange is that the other person has to respond to you.  What if you just
want to send them an encrypted load right off the start.   You can't 
really do it.

The solution is (and always has been) to do a lookup.  The problem is that
there is no directory to look up from.   Global X.500/LDAP directories are 
*never* going to happen.

There is only one choice -- DNS.   I (and Steve Kille and others) have 
been flogging LDAP directories and working on LDAP/X.500 interconnects for
a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

> bypass the initial insecure e-mail exchange ?

Precisely.   They must be able to do a DNS lookup for the information 
either as a direct data return or a reference to a secondary storage 
service, which absolutely could and probably should be LDAP.   To 
work in practice I think that it should be possible to get a direct pull 
from the DNS so that organizations are not required to deploy an LDAP 
directory and all that goes along with it (much as that pains me).
 
> configuration for the most part (it could just be turned on or off).

Actually, I think that "fishing" is an entirely appropriate thing to do.  
The worst that can happen is that don't find the cert your looking for.   
Trust issues MUST be dealt with, but certificate trust chains and 
approaches are both well understood. 

The best that can happen is that suddenly I can go and find a cert for 
[email-masked] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want 
to do that?

This does lead very nicely into my second (and quite separate) issue in 
this area -- the "trusted ROOT certificate".   Julien has provided superp 
leading commentary here.
  
> whose ISP isn't a CA (99.9% of them right now). 

Exactly.   Why?   Because it costs TOO MUCH.   The only acceptable cost 
for most ISP's is zero because of the volume of users.   Cost of 
certification is, pure and simple, the primary barrier to the general use 
and deployment of S/MIME on the Internet.

The reason for the cost is that the mechanism for establishing root trust 
is determined solely by the set of ROOT certificates distributed by the 
client vendor -- of all things!.   Thus only those organizations that can 
afford to pay the client vendor -- of all things! -- to be included in 
their "special trusted root certificate club" get to have "trust".   Which 
means that you MUST buy certs from one of the club members.  Doesn't THAT 
just suck.   Nice business if you can get it.

<qualification>
Yes I know about free thawte certs.   I know that any root issuer must be 
secure and provide good protection from having roots keys compromised etc. 
I agree that anyone who issues certificates should be required to be 
secure. I understand that there is risk to the client vendor if they 
report trust in a cert that has been compromised at the root.

Regardless, to have this power rest in the hands of the client vendor is 
ludicrous.   Why should I trust that Microsoft can evaluate the security 
and trustworthiness of "Joe's CA Service" to be a valid issuer.   I'm not 
saying they are unqualified to do so, but I'm a lot more likely to trust a
self signed "Bank of America" certificate issued on it's own behalf and 
obtained from a reliable source, than I am a third party software vendor 
or CA Verisign (not that there's anything wrong with either Microsoft or 
Verisign :-).
</qualification>

The issue comes down to trust brokering.   I just don't think that it is 
working for the *general* mass consumer Internet.   It clearly does work 
for closed communities within the Internet, but it isn't scaling.   
Period.  If we want generalized S/MIME usage throughout the Internet we 
need to think of some mechanism that is:

1.  Easy to deploy.   The track record for the Internet stongly indicates 
that this means that there are freeware versions of software that will 
support the deployment.   This includes both the key management and 
publication software and the usage (client) software. 

2.  Free.   Those who "own" the vast majoritiy of the user population on 
the Internet are ISP's.   They have almost no margin and simply cannot 
afford to pay for certification.  Also (and more importantly IMHO) is the 
desired for businesses to touch their customers.   These are HUGE volume 
relationships in which there are virtually no economically viable ways of
establishing bidirectional trust.   A cert price of $0.01 a year is too 
much if your customer population is 25 million people (banks, utilities, 
etc.)

Why could we not have organizations issue certificates distributed via 
DNS, with a trust relationship provided by DNS-SEC?  That is, you can 
trust that the DNS node your are dealing with is legitimate because they 
have deployed DNS-SEC (which everyone should do anyway for a host of other
security reasons) and the keys that are located within the DNS hierachy 
are legitimate.

I can then lookup certs based on mail address (duh!), where the mail 
domain source is trusted because of DNS-SEC.   This trust relationship 
could be either:

implicit -- the issuer domain location is trusted therefore any keys 
published there are trusted,

explict -- the issuer provides a root signing key which is in turn signed 
by their DNS-SEC key.

There are a number of observations that can be made about this approach:

1.  The security provided by the approach is probably not as strong as the
full commercial CA approach.   I contend "so what".   It's better than 
nothing and Pretty Good (pun intended).  The average user doesn't need 
military grade security.   The average bill issued by the local telephone 
utility doesn't need military grade security.   Think of the vast number 
of paper documents that need only Pretty Good security and trust to be 
useful (292 Trillion a year in the US -- it's my business and I happen to 
know).  All we need is some security to make that paper go away forever.

2.  Some extensions to bind and a new CSP for Windows would get a large 
number people going in a hurry.   Openssl with an HSM card and some 
reasonable security policy has an organization running pretty quickly.

> The only solution for 
> these users is some sort of universal registration service. 

Yup.

> This implies 

Well, even though I would love it if it was LDAP, it isn't going to 
happen.   DNS is the only game in town for global directory service.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: [email-masked]
Phone: 780 424 4922

---

From: [email-masked] (Julien Pierre)
Date: Thu, 14 Aug 2003 19:58:11 -0700

Steve,

 > S/MIME by the masses on the Internet.   Why hasn't it happened and what

Yes, that's exactly the problem that prompted my questions. And it's 
coming soon to an AOL mail program near you ... Some of you may have 
heard of this new "AOL Communicator" mail program that was released in 
the last week to the masses. In fact this program already includes 
S/MIME support.
Hopefully, solving this problem doesn't necessitate new specs and 
completely new services and products, but only minor tweaks and 
clarifications of how to use the existing technology.

 > want to exchange mail with.

This is supported today in Mozilla mail, Netscape 7.x mail, and AOL 
Communicator.
In fact, in our internal PKI deployment we use different keys for 
encryption and signing. This results in the issuance of two different 
certificates, one for signing and another for encryption.
The digital signature can be configured to include a different 
certificate for encryption. Look at my signature in this message and see 
if you get confused : I signed it with my corporate certificate, but I 
included a recipient Thawte encryption certificate.

 > want to send them an encrypted load right off the start.   You can't

That's right, and it's the whole problem I have been asking about. 
Exchanging unencrypted messages first, in my opinion, is not a solution.

 > there is no directory to look up from.   Global X.500/LDAP directories

Why ?

 > a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

Can you summarize why ?

 > directory and all that goes along with it (much as that pains me).

I think other people have pointed out that DNS itself is not suited as 
the repository for the certificates.
Since the query starts with only the e-mail address, which contains a 
userid and domain, I think it is appropriate to start the lookup in the 
DNS. There should be a standard schema to get to the appropriate LDAP 
server from the user's e-mail domain. The certificate would then be 
looked up from it. The client application could also fall back to a 
"default" LDAP server if the DNS query fails to find the appropriate 
directory.

 > Actually, I think that "fishing" is an entirely appropriate thing to do.

I didn't say it wasn't, I just have reservations on how it's done (see 
above).

 > [email-masked] with a simple DNS query.  BEAUTIFUL!   Why wouldn't I want

Sounds good, but we have to make sure this is deployable for a lot of 
people. I don't really see how it would be.

If LDAP is used to store the certs, perhaps all a domain owner might 
have to do would be do add an entry in the DNS, either with a new record 
type, or even simpler for quicker deployment, a standard name, eg 
pki-public-ldap . This entry could be pointed to some free public 
directory if the ISP doesn't want to run it itself.

 > and deployment of S/MIME on the Internet.

I think you have it backwards, cost of certification is way down on the 
list of obstacles to mass deployment of S/MIME right now. Let me mention 
some other important barriers  :

1) the general public is completely unaware that certification even 
exists. I think this is the #1 issue by far.
Many companies have been trying to raise awareness for PKI, but none 
have succeeded in getting the masses to adopt it yet.

2) the value of certification is low today because there are so few 
certified users, and encryption only works between certified people. 
This is like being one of the first one to have a telephone.

(Even worse than that, without even having a directory in existence to 
find out who else you could communicate with - this is the problem at 
stake).

3) S/MIME is too complex to use

I don't believe the first issue can be solved by any specifications or 
talk in this group, but several companies will continue to work on it. 
Hopefully they will succeed.

The first two issues are related. As more people become aware of 
certification and certified, the value of being certified will increase. 
I believe the cost of the certification will be much less of an issue 
once people realize they are paying for a something useful.

IMO, the certificate dissemination issue remains a major obstacle. Even 
if lots of people were certified today, it would still be very hard to 
know who they are and communicate with them.

The complexity of S/MIME usability is also something the group has 
impact on. The specifications heavily impact the implementation and 
usability of S/MIME client software.

 > just suck.   Nice business if you can get it.

Yes, vendors have to ship a certain set of roots. We can't just 
automagically trust every self-signed root there is. We ship with about 
a hundred roots already though. It is true Netscape has charged in the 
past for including it. Microsoft requests that your root goes through an 
independent certification process. Either way, the process costs a lot 
of money.

You aren't limited to using the roots that are shipped.
You can add your own roots if you want to trust it. All it takes is a 
couple of clicks in the client application.
If you don't like your users having to click, you can pull a Mozilla 
source tree, and add your very own root certificates and mark them 
trusted if you like. It is a simple process and I'll be happy to show 
anyone how to do it, as I have been the one checking in the roots to the 
official tree. Any ISP could do it. Any CA could do it. Any corporation 
could do that.

 > or CA Verisign (not that there's anything wrong with either Microsoft or

All the client vendors do is provide a default trust domain, which is a 
list of well-known root certificates with trust settings. What do you 
want them to do ? Ship with no roots at all ? Automatically trust every 
single self-signed root under the sun ?

The default trust domain that ships with client software is not static. 
Like any other software setting, it can be configured. Any user is free 
to add another root and mark it trusted.
If the trust domain was static then you would have a point, but as I see 
it, you miss the point.

 > publication software and the usage (client) software.

At least we agree it needs to be easy.

 > much if your customer population is 25 million people (banks, utilities,

The price figure you cite is absurdly low. Do you really, seriously 
think $250,000 to enable secure services matters much to a company with 
25 million customers ? Certainly it wouldn't matter much to a bank, 
especially since it would probably reduce certain mailing costs. I'd 
guess that even one bulk USPS communication is going to cost more than 1 
cent per recipient. I only know one ISP with 25 million customers or 
more, and I happen to work for it, but I'm not at liberty to comment 
further on the costs.

The bottom line is, running a CA is a service, and it costs money, 
probably far, far more than $0.01 per cert per year. Whether an ISP runs 
it itself or outsources it, the service is going to cost some money 
somewhere

Anyway, I think we are getting quite off-topic here. If people want to 
run a loss-leader cert service they are welcome to do so, just as 
Thawte/Verisign does. I don't know how much relevance this has to the 
mailing list. Or do you want to codify the prices of certificates into 
the RFCs  ?

 > explict -- the issuer provides a root signing key which is in turn signed

What you are proposing is a new policy to automatically trust the 
certificate because of the security of the channel it traveled through.
But there has to be some prior trust somehow for the channel itself. I'm 
not familiar with DNS-SEC. Does it involve SSL/TLS in any way ? If so 
there would have to be prior trust on the DNS server certificate too.
All in all, I think the implicit trust is very dangerous. It is one 
thing to accept information through that channel while it is open, but 
to continue to use it after it is closed, by automatically trusting the 
certificate that was transferred, is another.
You may argue that it is better than nothing, however, a false sense of 
security may be worse than knowledge of the lack of security.

 > happen.   DNS is the only game in town for global directory service.

I don't see why the lookup has to be a 1-part lookup. It could - and 
probably should, given the size of the problem - take more than one step.

-- 
I am the dog in dogfood

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 15 Aug 2003 09:06:50 +0200

May I add some naive thought to the table?

That the issuer is of great importance for signatures and authentication
purposes is undoubtedly true.

But I cannot really say that I see the same need for TPP-issued encryption
certificates.  Is there even a need for encryption-certificates?  It seems sufficient
that users in their e-mail client create key-pairs and publish the public
key in the associated domain.  If you trust the lookup service like XKMS
why should this not be enough?  Well you could actually create a self-signed
certificate in your mail client and send a signed message (using
a trusted signer cert/key) containg the generated encryption key or cert to
encryptionregistry@yourdomain to get it automatically published.
No apparent need for CAs and associated root and path validation
for encryption certificates.

XKMS introduces an optional trust-anchor itself but that would not
work (scale)with encryption certificates for a global Internet.  So no
matter what you do, there will be lose ends on all lookup solutions.
Only the hard transfer-the-globally-recognized-TTP-certificate-out-
band will be "fully secure" and we already know that this does not
support the more dynamic scenarious we are currently discussing.

For enterprise usage I doubt that end-to-end encryption is of much value
as lost keys create too much hassles.  Most business systems are likely
to rather use HTTPS which is easier to handle than S/MIME encryption.

Anders

----- Original Message ----- 
From: "Steve Hole" <[email-masked]>
To: "Julien Pierre" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 14, 2003 19:30
Subject: Re: dissemination of public encryption certificates

 

  

<qualification>

Yup.

Cheers.

---
Steve Hole

---

From: Steve Hole <[email-masked]>
Date: Fri, 15 Aug 2003 10:30:11 -0700

> Why ?

Because you have to run a root.  That is, the hierarchy has to have a top 
level interconnect.   This quickly becomes an issue of governance.   
National goverments get involved the way they got involved in DNS.   The 
difference is that the governments got involved *before* the service was 
running, not after the way they did with DNS.

There is a long track record of attempts at establishing global X.500 
whitepages services.   There were several attempts that I participated in 
that just didn't gain traction.  I think in retrospect it was primarily a 
cost issue again.   The *business* people and organizations who had 
interest in participating couldn't stomach a "build it an they will come" 
approach when there were real costs and somewhat amorphous benefits.   
People just don't get why you need it and the formal delegation and 
governance rules made it non-trivial to set up.

Note that I said "Whitepages".   Regrettably, PKI information at the 
global level was always linked to other personal information that would 
aid in the search and retrieval of useful information on people.   This 
was a goal that I happily promoted and thought "was a great idea".   
Wrong.   What I (and many others) never thought about was the privacy 
concerns.   Sure the system is secure and access controlled etc etc.  But,
the governance issues around actually making this information available on
the Internet was really huge.   By the time some of this was figured out, 
the perception had become that none of it was truly deployable.   Very few
commercial organizations (government doesn't count) wanted that 
information available and didn't believe that secure interpersonal email 
(the one obvious use application) needed that level of support.

There were some not insubstantial technical hurdles with root management 
and scaling as well.   Problems that probably could have been (and were 
for the most part) solved, but took long enough to solve that 
people just didn't believe.   Basically, there was enough disinterest that 
the whole thing just stagnated.

Finally, the one thing that could have driven the service -- storage of 
keys -- was itself a substantial cost item because of the cost of 
certification.   While certification costs have dropped, in the beginning 
they were excruciating and only the richest could play.  Therefore, there 
never was a groundswell of use that demanded that the "situation be 
improved".   You need a Web like uptake to get the necessary 
infrastructure allocated and serviced.

In short there was always a substantial cost.   My experience with the 
Internet is that the only things that successfully deploy to Internet 
scale are things that start with the groundswell of the common user.  It 
has to be easy and it has to be (near) free.

>  > a decade.   Global X.500/LDAP isn't going to happen in our lifetime.

Pretty much did above :-)

For what it's worth, I am NOT saying "LDAP is useless".  What I'm saying 
is that you need to leverage the one and only global directory service the 
Internet is ever likely to successfully deploy to get to your LDAP (or 
XKMS) services.   Then we avoid the governance, root and cost issues 
associated with global directory whitepages.

> "default" LDAP server if the DNS query fails to find the appropriate 

Works for me.   More LDAP servers sold then :-)

> directory if the ISP doesn't want to run it itself.

I think we are in agreement.   That was easy :-)

As noted in other messages the practical hurdles for deployment center on 
management (key issuer) and client (user).  Unless something is specified 
there is no hope of even getting to those hurdles though.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

---

From: Steve Hole <[email-masked]>
Date: Fri, 15 Aug 2003 12:48:59 -0700

I broke the reply into to parts because they really are quite separate 
issues.   This topic deals primarily with the issuance of certificates and
trust management in deployed S/MIME clients.   I debated taking it 
offline, but I think that it is useful discussion from a usage point of 
view.   It has little technical merit on a primarily technical forum, but 
it has overall import for S/MIME -- I hope :-)

> This is like being one of the first one to have a telephone.

OK.  Before I go on, I will state that I agree with both of these 
assertions on an individual basis.   The issue is really how many of these
things work in combination to stall or make S/MIME usage difficult.

I see that we need to talk a bit about the usage models that are evolving 
on the Internet. There are at least two with variations:

1.  Interpersonal secure mail.   This is Mom exchanging secure email with 
Aunt Jane on the other side of the country.

2.  Organizational communications.   This is the business to consumer or 
organization to partipant communications (ie. my bank wanting to send me 
statements and me wanting to complain to my bank).

<apology>
Because I am so focused on usage model 2 these days I tend to forget about
usage model 1.   My apologies.   Conversely, I suspect that very little 
thought has gone into usage model 2 as it is an entirely new thing for 
business to be doing on the Internet.
</apology>

So what?   Your assertions and the priority you assign them are spot on 
for usage model 1.   I would still add both cost and complexity of 
certification to this model.   For Mom to sign up to get a cert is 
actually pretty daunting from a user interface point of view.   We and our
customers have done lots of user tests and it is a problem. 

My assertion that cost is a big deal is very applicable to usage model 2. 
In this case organizations want to certify their consumers for secure 
document receipt and (possibly) reply.   Outbound is fairly easy -- just 
issue an encryption only cert to the user on enrollment.   No trust issues
and it is reasonably easy to get to the user's desktop.   The problem 
comes when you want bidirectional communication and are therefore issuing 
signing certs.   The cost of doing this for millions of customers is so 
high using the existing certification model (because of root trust 
requirements) that to use S/MIME becomes impractical or forces alternative 
solutions.

There are a series of companies that provide "e-mail encryption" using 
proprietary formats and Javascript symetric decryptors that completely 
bypass S/MIME altogether.   And people buy it!  BIG organizations buy it.  
It's depressing.   And when talking about S/MIME it has to be concern to 
this group and people who implement S/MIME clients.
 
> find out who else you could communicate with - this is the problem at 

Correct.   This means that interpersonal secure email usage is 
impractical because there is no way to obtain necessary security 
information for an arbitrary recipient.   This is the original stated 
problem and we all agree that it is a major, if not the major barrier.

I think that we have some good concensus building on that and maybe there 
are some actions that we can now take to try to resolve the issue. 
 
> 3) S/MIME is too complex to use

S/MIME isn't so complicated (at least our user testing doesn't indicate 
that).   We get very few usage calls back to customer support.   

Certification is certainly complicated.   Even the easiest of the 
commercial (Verisign) CA's are quite daunting to the average user. This is
an implementation issue that needs some work.   This accounts for better 
than 95% of our TOTAL service calls.   Ouch!
 
> Hopefully they will succeed.

The only way to solve it (I think) is to have organizations initiate 
certificate issuance.   That is, ISP's need to offer to do this as part of 
their enrollment.   

Certificate awareness is very high in my usage model 2 because either Joe 
Customer wants to get e-documents from Sam Business or Sam Business wants 
Joe Customer to get e-documents.   Either way, there is explicit 
communication that initiates certification (in all the various ways that 
can be done).

So it is a question of how do we initiate certification?   More 
importantly how do we get ISP's (or a proxy third party) to engage users 
in the certification process. 
 
> once people realize they are paying for a something useful.

No it won't :-)   Will your Mom pay to be certified?   I know for a fact 
mine won't because I tried to get her to get a Verisign cert and when she 
found out it was $20, that terminated that conversation quickly :-)

It will improve yes, but you won't get anywhere near universal uptake.
 
 ... some stuff skipped ...
 
> official tree. Any ISP could do it. Any CA could do it. Any corporation 

You are right.   I knew when I was writing that part that I was going to 
get into trouble :-).

First of all, this problem really is a usage model 2 issue.   An 
organization wants to certify a very large number of users.  It really 
doesn't apply to usage model 1, for which most of the existing S/MIME 
clients are targeted.

> If the trust domain was static then you would have a point, but as I see 

All of the above is correct.   I'm saying two things:

1.  It would be very nice if there is some way that the trust domain could
be removed from client configuration to a centralized service.   This is 
simply good engineering and allows for dynamic control over what is 
trusted and what is not.

2.  Modifying desktop settings to support security policy and certificate 
issuance is a non-starter for usage model 2.   It's the old adage -- 
people want security but they don't want to have to do anything to get it. 

I'll give you an example that might help.   If My Huge Bank wanted to 
issue certificates to their users to establish a secure email community of
trust, then they have two choices: acquire certificates from one of the 
CA's that is already in the "trusted root" category or try to issue 
self-signed certificates and become a trusted root.  Cost is a big barrier
in the first option.   Deployment complexity (and some cost) is a barrier 
for option 2.   Because a new root certificate has to be downloaded to 
every desktop you've got a deployment latency problem.   Because it costs 
(in some non-insubstantial set of S/MIME implementations) to get a 
registered root certificate, the costs of this are not insubstantial 
either.

If the cost that an organization like My Huge Bank will bear to roll out a
new service is $1M - $500K you can see that the cost of deployment for an 
S/MIME solution is severly compromised by the costs of certification.   
Companies and solutions like Tumbleweed exist that provide alternatives to
S/MIME simply because of this fact.

If we could arrange things to avoid the cost and provide zero deployment 
latency, that would greatly enhance usage model 2 scenarios and make life 
difficult for non-standard email security solutions.
 
> more, and I happen to work for it, but I'm not at liberty to comment 

First of all, $0.01 per cert for 25M customers is $2.5M annually. 

You need to go have a look at who I work for :-)

The example that I give above is by far the rule.   The costs that even a 
large bank with 25M consumers will bear for *any* Internet application is 
quite low at this point.   Most of that has to do with the series of 
disappointing Internet applications and middleware that were invested in 
over the years has seriously damaged their trust in real return on 
investment in Internet applications.

The *only* reason that we can sell secure document delivery systems to our
customers with S/MIME based security is that we do one-way encryption only
solutions which obviates the need for signing certs and trust.   Even with
that, many of our customers find the simple certification issuance that we
do (two dialogs and a single page turn) too much and want to use password 
based encryption instead.   We have been forced to write an S/MIME viewer 
application that supports the S/MIME shared secret profile because very 
few of the shipping clients support it yet.
 
> mailing list. Or do you want to codify the prices of certificates into 

Agreed, we can take the remainder of this conversation off line.  

However, it is important to note that the cost of running a your own CA 
today is largely a matter of the licensing costs of running the CA 
software.   There are operational costs, but those costs can and should be
part of the cost of operating the application the uses S/MIME.   We do NOT
charge for certificate issuance in our product.   We charge for documents 
delivered. There is a direct and easy comparison for any usage model 2 
document issuer to compare the cost of paper mail to secure email.   If we
had the ability to "Register" a self certifying organization root 
certificate in one place (not one for every desktop client) that would be 
a huge step forward.

Cheers.

---
Steve Hole

---

From: [email-masked] (Julien Pierre)
Date: Fri, 15 Aug 2003 17:37:10 -0700

Anders,

Anders Rundgren wrote on 08/15/2003, 0:06:

 > why should this not be enough?

Certificates establish a permanent, traceable link between the user's 
identity and the public key.

If I correctly understand what you propose, the XKMS service would 
provide a temporary link between the user's identity and the the public key.

One reason this link isn't enough is revocation. If the key gets 
compromised at some point, how do you indicate at a later time not to 
trust that key anymore ? And how do you do it retroactively ?

Correct me if I'm wrong, but most revocation systems today are based on 
CRLs rather than KRLs. The government was the only user of KRLs but even 
they are using CRLs now. Most software as a result primarily supports 
certificate-based revocation, not key-based revocation.

 > Well you could actually create a
 > self-signed

It should be a policy of the repository however to decide whether or not 
to apply path validations for certificates it stores. Certainly one 
could decide not to do any validation if they so chose.
However eventually, when an end user does a query, they most likely 
won't trust that self-signed certificate due to their trust domain 
configuration. So it would not be in the interest of the repository to 
have too lax of a policy on cert issuers.

 > support the more dynamic scenarious we are currently discussing.

It can work if there is a set of well-known accepted trusted roots. I 
don't think every single random root should be automatically trusted. 
What's missing is a way to easily replicate the trust domain - ie. let 
the repositories dynamically add roots once a new CA goes in business 
and gains acceptance.

 > to rather use HTTPS which is easier to handle than S/MIME encryption.

HTTPS and S/MIME have different uses and benefits. If you sign a 
contract over HTTPS there is no persistent proof, whereas there is with 
S/MIME.

The problem of lost encryption keys for enterprises is already solved 
with key escrow. All the necessary mechanisms are already in place 
today. Most businesses want to be able to access their employees' 
communications anyway, so there is another reason that they use key 
escrow for encryption keys. Signing keys are of course a different 
matter and should not be escrowed.

-- 
I am the dog in dogfood

---

From: [email-masked] (Julien Pierre)
Date: Fri, 15 Aug 2003 20:10:16 -0700

Steve,

 > it has overall import for S/MIME -- I hope :-)

I would also have taken most of the discussion offline already due to 
the direction it is going if there hadn't been many people expressing 
their interest in the topics.

 > business to be doing on the Internet.

No need to apologize. Likewise I focused mostly on the first usage due 
to the fact that I work for an ISP. However I believe the two uses very 
often intersect. Consumers want to make secure electronic communications 
with businesses (I know I do), which they can't do by e-mail today. 
S/MIME certification allows both.

 > customers have done lots of user tests and it is a problem.

The complexity was my third one on the list - how S/MIME is difficult to 
use . That included the enrollment process.  I completely agree it is 
very daunting. Actually I have gotten my mother running on S/MIME so I 
know what you are talking about when you mention complexity of 
enrollment. I got her running with Thawte and it was quite long to 
enroll. But there is no reason that it has to be that way - it entirely 
depends on the CA.

 > requirements) that to use S/MIME becomes impractical or forces

I'm not sure I understand why the trust is less of a problem for 
encryption certs than signing certs.
If you want to receive encrypted communications, you need to create an 
encryption key and cert. And you need to make the other party aware of 
it. Typically in S/MIME today this transfer of the public encryption 
cert is done by ... signing an e-mail. Which requires you to have a 
signing cert...
Otherwise the user could also publish the encryption cert to LDAP.
Still there would need to be some authentication at that time.

 > this group and people who implement S/MIME clients.

What are the advantages of these pseudo-security products ?

 > are some actions that we can now take to try to resolve the issue.

While we don't have any consensus yet on the technical direction, I 
would certainly be willing to participate in writing a draft that would 
make recommendations on additional ways to distribute S/MIME 
certificates. Of course the actual deployment of a global directory is a 
problem, but perhaps by having this draft written by people involved in 
companies potentially interested in using/running it we will end up 
writing a deployable proposal.

 > than 95% of our TOTAL service calls.   Ouch!

Yes, that's what I meant. Enrollment is part of the usage of S/MIME.
I had to sit with my mother last year to get her to sign up, and I 
talked to her at length at international rates for the recent renewal.

 > certificate issuance.   That is, ISP's need to offer to do this as

Agreed.

 > in the certification process.

I wish I had the answer to that one.

 > found out it was $20, that terminated that conversation quickly :-)

Yes, I know the feeling, I got the same reaction from my family members, 
which is why I got many of them to enroll with the freemail Thawte CA 
instead.

However the service doesn't have to be directly paid for, or all at 
once. It can be bundled by the ISP with her account. Even if it wasn't 
bundled with every account, the one-time $20 might be only a $1.66 
option/month extra, which is the same price, but suddenly doesn't look 
so bad. Especially if that $1.66 buys you more than just the ability to 
communicate with family members, but also with businesses (ie. banks).

 > doesn't apply to usage model 1, for which most of the existing S/MIME

Still, a corporate organization can run its own CA which doesn't have to 
be a root CA.

 > simply good engineering and allows for dynamic control over what is

I think it cannot ever entirely be removed from the client, because you 
need to start with some trust, but it could be aggregated.
Before this can be dynamically controlled however, the very notion of 
what a trust domain is needs to be defined and standardized. Then we can 
define means to transfer it, through existing protocols hopefully.

 > S/MIME simply because of this fact.

My huge bank doesn't have to run a root, my huge bank can run a CA and 
get it signed by one of the root CAs. Then it doesn't need to deploy a 
root to every desktop.

If it insists on running a root, there is going to be at least one 
config change to make it happen. Right now I think it is as simple as 
clicking on a URL and accepting a dialog. I don't know how much simpler 
one can make it.

Yes, a means to distribute the trust domain (see above) would help, but 
one would still need to configure the software to use the distribution 
channel - whatever it would be (HTTP, LDAP ...). I don't see how this 
would be simpler than the click and confirmation of the dialog.
The only advantage is that you might only need to enable that trust 
domain service once, and several organizations could publish their root 
to it. You could imagine for example a consortium of financial 
institutions ... Of course the consortium could just have one root and 
bear its cost, and issue one CA for each institution.
FYI, I believe Microsoft might already update roots when you do a 
windows update, but of course that's a proprietary solution, and you 
still have the upfront cost of getting certified when you create your root.

 > First of all, $0.01 per cert for 25M customers is $2.5M annually.

No, it is $250,000 .

 > You need to go have a look at who I work for :-)

The name doesn't ring a bell, but I will check.

 > quite low at this point.

First class stamps are up to 37 cents last time I checked. I don't know 
what the bulk rate is, but using your (unrealistic) proposed cost of 1 
cert per cert, the investment would pay for itself at the first paper 
communication saved even if only 3 percent of the bank customers ever 
used their cert. Of course, it's up to the banks to decide what's 
beneficial to them, but if something is going to save them so much 
money, the bank has responsibility to their shareholders to look into 
it. I don't have any more to add on this topic.

 >   Most of that has to do with the series of

Someone has to do it right first. Competitors will follow. Same thing 
happened with online account access - not everybody offered SSL. Lots of 
banks erred in offering proprietary software solutions for a while. It 
sorted itself out. We are just at an earlier stage in the process.

 > certificate in one place (not one for every desktop client) that would be

Even if that service existed, it would still need some kind of client 
configuration to point to that one place.

-- 
I am the dog in dogfood

---

From: Vadim Fedukovich <[email-masked]>
Date: Mon, 18 Aug 2003 14:34:49 +0300

On Fri, Aug 15, 2003 at 10:30:11AM -0700, Steve Hole wrote:
> level interconnect.

really?

I believe RSA works fine both for subject name matching issuer name
and for any other subject name. One could put trust directly in some
CA certificate (say, a corporation-wide one) and it could be root,
self-signed or otherwise. Fine-tuned client software is the point

>   This quickly becomes an issue of governance.   

One can easily sign with DSS/DSA using widely distributed quorum system,
maybe Shamir secret-sharing one. No single one would own
the signing key and it could be generated in shares right from the start

regards,
Vadim

---

From: Steve Hole <[email-masked]>
Date: Mon, 18 Aug 2003 10:14:58 -0700

> Still there would need to be some authentication at that time.

If you either (1) engage the desktop keypair generation CSR issuance or 
(2) generate a keypair and deliver it via PKcS12 at enrollment time, then 
you can issue data encipherment only key-usage keys that are only used for
encryption.   The keys can be self signed and really are only ever used to
decrypt data sent from the document issuer and cannot be used for signing.
By doing this, you avoid all root signing issues and all of the extremely 
nasty UI that prevents people from enrolling and generates calls to 
customer service.   The certificates need to be validated before we use 
them to encrypt, but that is all local security policy and we do a lot of 
stuff beyond normal certificate validation to make sure our certs are 
valid.   Once encrypted, the user just needs to have the private key to 
decrypt and the cert is really only used to keep the cert store happy on 
the desktop.

I talk about cost a lot.   The average cost of a call to support is $18, 
so it needs to be avoided at all costs (pun intended).

The interfaces provided by IE and/or Netscape provide much simpler, not so
"in-your-face" UI for cert management when there is no trust involved.
 
> What are the advantages of these pseudo-security products ?

They avoid certification.

They address the 36% of the Internet that doesn't use or have access to 
S/MIME software -- primarily AOL, Yahoo!Mail and Hotmail.   If your in a 
model 2 scenario you MUST do something useful with those and the solution 
is psuedo security.   Interestingly, it seems good enough for most people,
especially if it avoids calls to service reps.

This sucks!
 
> communicate with family members, but also with businesses (ie. banks).

Well, I'm not an expert on ISP business models.   Everything I've ever 
been told suggests that there is almost no margin in the business model 
and additional costs are hard to bear or pass through.   For this you have
to convince the masses that security is what they want, and I can tell you
from experience that that is a very difficult thing to do.   And my 
experience comes from a business usage perspective where the content 
definitely is sensitive in nature -- much more so that most email between 
Mom and Aunt Jane.
 
> Still, a corporate organization can run its own CA which doesn't have to 

If you can acquire a delegated cert.   We haven't check recently, but 6 
months ago we couldn't buy one.    Thawte used to sell them for $100K, but
since have discontinued because there was no business there.   We should 
go check again.   It was the simple and obvious thing to do, but because 
there was nobody doing it, the service wasn't offerred by the CA's.   
 
> define means to transfer it, through existing protocols hopefully.

The client would have to have some secure means of "synchronizing" it's 
cache to a centralized service.   You get this with Microsoft services by 
downloading a cert package from Windows Update.   The problem is that it 
only works for Windows products (at least that way) and we need something 
that is vendor independent.   The approach seems OK to me as long as it is
"automatic".
 
> get it signed by one of the root CAs. Then it doesn't need to deploy a 

Seems logical.   In practice we were unable to make it happen.   We needed
to go through special negotiation because it wasn't a standard service 
offering and there was a serious price issue for the signing cert.
 
> clicking on a URL and accepting a dialog. I don't know how much simpler 

In Netscape, yes.   In others no.   You actually get a Hex dump of the 
cert with a message that says something like "Do you trust this 
certificate with policy blah blah".   About 45% of the test group stopped 
at this point.   Most of our customers simply said "too complex, too 
scary".

Yes, I know it should be scary etc.   The problem is that the average user
just doesn't get it, doesn't want to get it.  It's a barrier to uptake.   
For the model 2 usage scenario uptake is everything because the economic 
benefit is based on paper suppression and resulting cost reductions.

That's all.
 
>  > First of all, $0.01 per cert for 25M customers is $2.5M annually.

Woops ... dislexic on the cost per cert.   The cheapest price we got was 
$0.10 (man, I *looked* that at least five times too - senility).  Anyway, 
the numbers weren't randomly chosen.  They were the numbers that we used 
in an actual RFP response in which the customer eventually took the 
one-way signing + encryption and decided against two-way with 
bidirectional signing.   The actual cost was $2.5M per year.

Security costs.  My example was intended to show that, in this instance at
least, it costs too much even for relatively rich organizations.
 
Cheers.

---
Steve Hole

---

From: [email-masked] (Julien Pierre)
Date: Mon, 18 Aug 2003 16:49:01 -0700

Steve

 > "in-your-face" UI for cert management when there is no trust involved.

It sounds to me like your grief is not with so much with the current 
trust model and PKI or S/MIME specifications, but with certain vendor 
implementations. I'm afraid that's something you have to work with these 
vendors.

 > especially if it avoids calls to service reps.

AOL will be taken care of, eventually. The newest client software (AOL 
Communicator) already supports S/MIME. There are still issues with the 
mail servers unfortunately so it doesn't work today. Encryption works 
through it, but signing doesn't (sigh).

Webmail in general is a problem and cannot be truly taken care of, 
unless the user is willing to trust his ISP with his private key - e.g.. 
by uploading a PKCS12 file ...

Another solution might be some sort of Java applet that would decrypt 
the message. But it would have to know about each webmail provider and 
the layout, so it would be icky.

Perhaps some standard for webmail is the only solution - e.g.. a MIME 
type transmitted over HTTP that would allow the browser to invoke the 
proper S/MIME client.

 > This sucks!

In general the users don't have only webmail access though, they 
typically have a mailbox from their access ISP which can work with the 
S/MIME clients that already exist today.

 > definitely is sensitive in nature -- much more so that most email between

I'm not an expert on this business model either either, but look at the 
latest AOL ads - "safe broadband", etc. This is certainly an area in 
which consumers are being educated right now, and security is something 
that consumers are getting interested in. I personally think there is 
hope for mass S/MIME deployment in the not so-distant future.

 > there was nobody doing it, the service wasn't offerred by the CA's.

We have had our own chained CA chained with a known public root at 
Netscape for years. We did change issuer a couple times. Our current one 
is GTE. I think previously we used Verisign. I wasn't the one dealing 
with it, and I don't know the cost, but I can tell you that the service 
exists. Since there are about 100 known roots now, you could go to any 
of them and ask about the service. I think I read year's that RSA 
Security was offering that service as well, and it cost less than $100k.

 > that is vendor independent.   The approach seems OK to me as long as

Yes. We need a standard way of distributing root. We also need a way of 
distributing trust, ie. a subscriber model.
It sounds to me like this proposal belongs on the PKIX list, so maybe we 
should move it there.
I don't see the root distribution problem as a major roadblock to 
deployment today since the services for getting chained CAs exists.

 > offering and there was a serious price issue for the signing cert.

Yes, it may not be a standard service, but if you need it there is far 
more than one issuer to go to these days.

 > at this point.   Most of our customers simply said "too complex, too

As I recall IE brings up something similar to Netscape when the root is 
untrusted. What is the "other" software that is so inflexible ? It seems 
to me that you need to take it up with the software vendor.

 > benefit is based on paper suppression and resulting cost reductions.

You can't require everybody to move to the S/MIME model at once. Even if 
a small percentage starts using it, the cost of printing and mailing is 
high. If you eliminate things like printed monthly statements, it 
shouldn't take a bank more than a small percentage of users to move to 
S/MIME to recoup its costs or actually profit.

 > $0.10 (man, I *looked* that at least five times too - senility).

That's still very low, but it's also likely less than the cost of 
printing and sending a single traditional communication.

 > Anyway,

I also know there are other financial organizations that spend much more 
on better security, and get more returns out of it. Look at credit card 
issuers starting to use smartcards. They have to bear the cost of the 
hardware in addition to the certs. They have millions of customers too. 
But some are doing it still (Amex). In Europe banks have been using 
smart chips on bank cards for decades. And believe it or not, they have 
been charging each customer to get those bank cards, too. Every bank 
over there is doing it though, because it reduces the transaction costs. 
We are not talking 10 cents per chip. With current generation smartcards 
they could afford to throw in certs for email as an extra and also 
eliminate the paper statements. Many of the issuers already have their 
own public roots to do it.

-- 
I am the dog in dogfood

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 19 Aug 2003 08:50:56 +0200

Some more on this topic.

Some TTP CAs (read: banks) have modeled their services after
their payment services.  e-governments have signed up such CAs
to supply citizen certificates.    Although I am fully convinced that
banks have an important role to fill in a TTP-based market (as
the on-line banking security requirements and on-line e-government
security requirements, are likely to be very similar), I strongly believe that
the four-corner model where each receiver (a,k.a. relying party)
must have
- a business contract with each trust network
- a unique relying party ID for each trust network
- a proprietary software installation for each trust network 
and pay for each revocation check, is something that governments
should reject.  For more details see:  
http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf

Another problem I see with this model is that it seems rather impossible
to support secure e-mail between individuals as e-mail packages
cannot easily match the requirements above.

Anders Rundgren
Consultant PKI and secure e-business