Subject: [pkix] Email in Certs and Privacy Concerns

From: Massimiliano Pala <[email-masked]>
Date: Tue, 19 Apr 2011 12:39:19 -0400

Hello all,

I was thinking about a privacy problem we have in currently issued certs:
email addresses.

Some CAs make the case that they do not wish to publish the list of certs
to avoid spammers to easily harvest all the email addresses in certs.

A simple solution would be to allow for using an hash of the email address
instead of the email address itself in the subjectAltName. This would
prevent attackers from using that information for spam/marketing purposes,
but still clients can easily verify the email address by simply hashing
the From: email address and compare the hash instead of the bare address.

This approach could be used also to protect hostnames, although I don't
see privacy issues there (maybe in some "special" environments?)

Since this addresses an important issue, shall we try to have a small and
quick I-D that describes the addition ?

Does this sound reasonable and easy to deploy ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 19 Apr 2011 15:33:33 -0400

I suspect that spammers, having gone to the trouble of harvesting
certificates, would not balk at building rainbow tables for the hashes.
There is not a whole lot of entropy in "localpart" @gmail.com,
@yahoo.com, @hotmail.com, etc.  Email addresses are not reused, so
salting doesn't help.  It may be a bit more difficult to enumerate
corporate, as opposed to public, email providers, but even so, this
sounds like a small deterrent to a dedicated spammer.

And if hashing gives a false sense of security, the harvesting step may
be made easier.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Massimiliano Pala
Sent: Tuesday, April 19, 2011 12:39 PM
To: [email-masked]
Subject: [pkix] Email in Certs and Privacy Concerns

Hello all,

I was thinking about a privacy problem we have in currently issued
certs:
email addresses.

Some CAs make the case that they do not wish to publish the list of
certs to avoid spammers to easily harvest all the email addresses in
certs.

A simple solution would be to allow for using an hash of the email
address instead of the email address itself in the subjectAltName. This
would prevent attackers from using that information for spam/marketing
purposes, but still clients can easily verify the email address by
simply hashing the From: email address and compare the hash instead of
the bare address.

Since this addresses an important issue, shall we try to have a small
and quick I-D that describes the addition ?

-- 

Best Regards,

	Massimiliano Pala

--o---------------------------------------------------------------------
---
Massimiliano Pala [OpenCA Project Manager]
[email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603)
369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603)
646-8734
--o---------------------------------------------------------------------
---
People who think they know everything are a great annoyance to those of
us who do.
							   -- Isaac
Asimov

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 19 Apr 2011 15:47:29 -0400

May be add a salt to the hash for good measure.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Massimiliano Pala
Sent: Tuesday, April 19, 2011 12:39 PM
To: [email-masked]
Subject: [pkix] Email in Certs and Privacy Concerns

Hello all,

Some CAs make the case that they do not wish to publish the list of certs to avoid spammers to easily harvest all the email addresses in certs.

A simple solution would be to allow for using an hash of the email address instead of the email address itself in the subjectAltName. This would prevent attackers from using that information for spam/marketing purposes, but still clients can easily verify the email address by simply hashing the From: email address and compare the hash instead of the bare address.

This approach could be used also to protect hostnames, although I don't see privacy issues there (maybe in some "special" environments?)

Since this addresses an important issue, shall we try to have a small and quick I-D that describes the addition ?

-- 

Best Regards,

	Massimiliano Pala

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us who do.
							   -- Isaac Asimov

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Apr 2011 22:09:30 +0200 (MEST)

> May be add a salt to the hash for good measure.

Different to Passwords, most users want Email addresses to be
easy to memorize for themselves _and_ all of their friends and contacts.

And spammers will use any technique that gives them new addresses.
They don't mind if the "quick approach" finds only 30-50% of those
addresses that exist.  They'll start with what they get.

-Martin

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 19 Apr 2011 17:23:24 -0400

Hi,

I understand the concern, but it seems to me we shall address this
issue somehow. Any other idea that could provide a viable solution
to this issue ? What about a little more "complex" hashing like the
following:

	Hash(Hash(pKey) + Hash(email))

Cheers,
Max

-- 

Best Regards,

	Massimiliano Pala

---

From: Tom Gindin <[email-masked]>
Date: Thu, 21 Apr 2011 10:45:12 -0400

How about just hashing the concatenation of SubjectPublicKeyInfo 
and rfc822Address?  At least it kills off reusable dictionary attacks, and 
the key's entropy is very high.  The second hash step doesn't buy you much 
against attempts to calculate the "top 20K addresses" and compare. 
Remember, the spammer is an ordinary RP who happens to be malicious, and 
anything the ordinary RP can calculate it can also calculate.

                Tom Gindin

From:
Massimiliano Pala <[email-masked]>
To:
[email-masked]
Date:
04/19/2011 05:29 PM
Subject:
Re: [pkix] Email in Certs and Privacy Concerns
Sent by:
[email-masked]

Hi,

Cheers,
Max

-- 

Best Regards,

                 Massimiliano Pala

[attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] 
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 21 Apr 2011 17:47:49 -0700

What is the point of the CA publishing certificates if I can't ask to find a
certificate by the email address?

The privacy question might be a different issue as once I give you a
certificate then I cannot control who you release it to and having minor
privacy at least makes you release two pieces of associated information
rather than just one.

Jim

> Sent: Thursday, April 21, 2011 7:45 AM
> To: Massimiliano Pala
> Cc: [email-masked]
> Subject: Re: [pkix] Email in Certs and Privacy Concerns
> 
and
> rfc822Address?  At least it kills off reusable dictionary attacks, and the
key's
> entropy is very high.  The second hash step doesn't buy you much against
> attempts to calculate the "top 20K addresses" and compare.
> Remember, the spammer is an ordinary RP who happens to be malicious,
> and anything the ordinary RP can calculate it can also calculate.
> 
>                 Tom Gindin
> 
> 
> 
> 
> From:
> Re: [pkix] Email in Certs and Privacy Concerns Sent by:
> [email-masked]
> 
> 
> 
> Hi,
> 
> I understand the concern, but it seems to me we shall address this issue
> somehow. Any other idea that could provide a viable solution to this issue
?
> What about a little more "complex" hashing like the
> following:
> 
> > And if hashing gives a false sense of security, the harvesting step
> > may be made easier.
> >
> > Dave
> >
> >
> > address instead of the email address itself in the subjectAltName.
> > This would prevent attackers from using that information for
> > spam/marketing purposes, but still clients can easily verify the email
> > address by simply hashing the From: email address and compare the hash
> > instead of the bare address.
> >
> > This approach could be used also to protect hostnames, although I
> > don't see privacy issues there (maybe in some "special" environments?)
> >

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 22 Apr 2011 09:18:52 -0400

Hi Jim, Tom, all,

[Tom: Hash]

Maybe I am missing the point, but if we use a simple concatenation, the
attacker could just use dictionary attack on the second part of the value,
right ? If you are proposing something like: hash(skid) + hash(addr), as
an attacker I would just ignore the first XXX bytes (from hash(skid)).
That is why I thought about re-hashing everything.

Of course, there is one issue with not using the addr value directly:
how to handle upper/low cases. In particular, although (if I remember
correctly) only the domain part should be case-insensitive, in practice
everybody treats all the parts of an email address as case-insensitive.
Therefore, if we agree on any form of protection for the email addr in
certificates, then the hash(addr) should probably be something like
hash(lc(add)) or hash(uc(addr)).

[Jim: searching]

Actually, searching for the certificate and the contents of the certificate
are, from a CA point of view, not correlated. Most of the CA software use
meta-data for certificate publication, not only the contents of the cert.
So, for example, you can have an LDAP server that has attributes like dn:
and multiple mail: . This allows a client to search with the mail: attribute
and retrieve the userCertificate;binary one. Then, by comparing the hash()
with the email addr used for sending the email, the client can pick the
right certificate.

So, we get the benefits for searching and when the certificate is used for
email purposes. But when used for other purposes (eg., SSL/TLS auth), the
email address is not automatically disclosed.

Does this make sense ?

Cheers,
Max

On 04/21/2011 08:47 PM, Jim Schaad wrote:
>> Massimiliano Pala<[email-masked]>
>> To:
>> [email-masked]
>> Date:
>> 04/19/2011 05:29 PM
>> Subject:

-- 

Best Regards,

	Massimiliano Pala

---

From: Tom Gindin <[email-masked]>
Date: Fri, 22 Apr 2011 18:11:40 -0400

Max:

        The value of the OTHER-NAME I'm proposing is derived by 
normalizing the e-mail address, concatenating it to the end of 
SubjectPublicKeyInfo, and hashing the structure which results from the 
concatenation.  I would specify that the e-mail address be converted to 
lower-case and then encoded in DER as a UTF8String before concatenation. 
Concatenating the hashes doesn't work for the reason you gave, but I did 
not propose that and I do know better than to do so.

                Tom Gindin

From:
Massimiliano Pala <[email-masked]>
To:
Jim Schaad <[email-masked]>
Cc:
Tom Gindin/Watson/IBM@IBMUS, [email-masked]
Date:
04/22/2011 09:19 AM
Subject:
Re: [pkix] Email in Certs and Privacy Concerns

Hi Jim, Tom, all,

[Tom: Hash]

[Jim: searching]

Actually, searching for the certificate and the contents of the 
certificate
are, from a CA point of view, not correlated. Most of the CA software use
meta-data for certificate publication, not only the contents of the cert.
So, for example, you can have an LDAP server that has attributes like dn:
and multiple mail: . This allows a client to search with the mail: 
attribute
and retrieve the userCertificate;binary one. Then, by comparing the hash()
with the email addr used for sending the email, the client can pick the
right certificate.

Does this make sense ?

Cheers,
Max

>> I understand the concern, but it seems to me we shall address this 
issue
>> People who think they know everything are a great annoyance to those of 
us

-- 

Best Regards,

                 Massimiliano Pala

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Apr 2011 15:58:46 -0700

Max,

>>> certs to avoid spammers to easily harvest all the email addresses in

Why do they want to publish a list of certificates that is not usable for
end-users?  What is the purpose that they would publish such a list of
certificates if the names were in some way shrouded?

Jim

> From: Massimiliano Pala [mailto:[email-masked]]
> Sent: Friday, April 22, 2011 6:19 AM
> To: Jim Schaad
> Cc: 'Tom Gindin'; [email-masked]
certificate
attribute
issue
[email-masked]
369-9332
646-8734

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 23 Apr 2011 00:57:16 +0200

>At least it kills off reusable dictionary attacks, and
>the key's entropy is very high.

No, it is 0 since it is known (even advertised in the cert.
Only unknown aspects of data contribute to its entropy (Straight from
information theory)

And that is the key. No matter how much you mix and re-hash stuff, if the
e-mail address is the only unknown data that goes into that calculation,
it is very easy to repeat that process with a guess of the e-mail address
to se if you are right.

And guessing e-mail addresses is often very easy.
Max proposal to mix upper and lower case characters randomly does make it
harder, but also makes it harder to use the solution as the valid verifier
need to know hoe to mix cases in the same way in order to validate it.
Smelling like RFC 1925 truth 6.

On Jim's comment on the other hand, I don't think hashing e-mail addresses
makes them unusable if there is a straightforward way to generate the
expected hash value of it and look up the cert indexed from a hash table,
but if you can do that, then you are all target of dictionary attacks.

It feels like if you want to do this usable, you need to do it so bad that
it is not worth the effort.

/Stefan

---

From: Tom Gindin <[email-masked]>
Date: Sat, 23 Apr 2011 18:13:11 -0400

Stefan:

        For the purposes of building an attacker's reusable dictionary, 
the key's entropy is very high.  For the purpose of building a one-time 
dictionary after receiving the certificate, it is indeed zero as you 
stated.

Tom Gindin

From:
Stefan Santesson <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS, Massimiliano Pala 
<[email-masked]>
Cc:
<[email-masked]>
Date:
04/22/2011 06:57 PM
Subject:
Re: [pkix] Email in Certs and Privacy Concerns

/Stefan

us

---

From: "Miller, Timothy J." <[email-masked]>
Date: Sun, 24 Apr 2011 14:24:09 -0400

Given than the use of an RFC822 name is *optional* under S/MIME v3 and later, why not just drop it from the cert and make the problem go away?

-- T

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Sun, 24 Apr 2011 12:23:05 -0700

List,

this shows, once again (see archives), that the security model for protecting
email with conventional PKC is backwards, technically and business wise. The
sender, who is the party at risk, finds herself in the awkward position of having
to rely on a lock provided by the recipient (his public-key) in order to protect
her secrets (the message).  Whereas the recipient risks losing privacy just by
getting a key cert.

If postal mail would provide message security a la PKC/PKI email, the sender
would have to convince the recipient to pay and send in advance an
envelope for the sender to use. The sender, however, would never know
whether the envelope indeed prevented others from prying into its contents
(translated to PKI: weak keys, escrowed keys, rogue CAs, etc.)

Businesswise, the recipient is also not the business driver who needs to provide,
pay for and protect the lock. The sender is the party who has the motivation to
spend money to provide and protect the lock.

Of course, PKC is a well-known and recognized standard (in various forms, including
PKI and PGP) for encryption of email. However, their security and usability 
problems
noted above just cannot be solved by improvements in usability, better pricing 
or user
education regarding how it works. It simply does not work as it should work. 
That's also
why conventional secure email has been difficult to use. It has the wrong logic 
for the
problem. This is a basic limitation.

Cheers,
Ed Gerck

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 25 Apr 2011 08:02:19 -0400

OK, granted.  So what's the alternative?  (And don't say identity based encryption or I promise I'll have you flogged :).

-- T

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Mon, 25 Apr 2011 12:55:19 -0700

> OK, granted.  So what's the alternative?  (And don't say identity based encryption or I promise I'll have you flogged :).

Well, using IBE encryption does not work because IBE requires sender 
key-escrow, and so the sender is always at risk that her messages can be read 
by someone else. In addition, key revocation has even less reliance than with 
PKI (yes, that is possible!). There are other problems as well.

The alternative should provide a compatible solution to conventional PKI and 
PGP secure email, so that there is no need for format wars and the extensive 
PKIX (and Open PGP) work can be used where it fits.  I also think that it 
should add first-contact and first-reply capabilities, as well as document 
lifecycle control functions, such as self-destruct (the certificate is 
short-lived and keys are destroyed).

This hybrid PKI/PGP solution is ZSentry Universal, based on Zmail (ZSentry 
Mail) and reviewed with PKI, PGP and IBE in (reprint) 
http://email-security.net/papers/pki-pgp-ibe-zmail.pdf

To comment, please send off-list as this is not a work item of PKIX (though an 
I-D may be submitted in the future).

Cheers,
Ed Gerck

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Apr 2011 02:02:05 +0200

I believe the closest we can come to an alternative is what was discussed
in the plasma BOF.

That is a model where you don't need the certificate of the recipient in
order to send an encrypted mail.
Instead you send an encrypted mail and deposit the key that the receiver
can obtain from a key server upon authenticating itself to the key server
according to a policy set by the sender.
That effectively avoids the need for certificate repositories for secure
e-mail.

That is also the model used for secure e-mail since many years now using
Microsoft Information Rights Management. The only problem with that is
that it is not X.509 cert based but XRML license based.

I think this is the kind of model secure e-mail needs in order to become
feasible.

/Stefan

On 11-04-25 2:02 PM, "Miller, Timothy J." <[email-masked]> wrote:

>OK, granted.  So what's the alternative?  (And don't say identity based
>encryption or I promise I'll have you flogged :).
>
>-- T
>
>
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 26 Apr 2011 08:52:37 -0400

That's nothing more than a walled garden email system; there are hundreds of these out there (look around the HIPAA compliance space) and really aren't any great shakes.

The problems are, off the top of my head:

- Prior arrangement between sender and recipient to select a TTP in common;
- Prior arrangement with the TTP to enroll keys and credentials; 
- Trustability of the TTP;
- Risks to the TTP key repository;
- Recovery after breach of the TTP;
- Secure authN to the TTP;
- AuthZ at the TTP.

I could go on if I tried harder.  MS IRM is no different (and has a couple additional problems, mostly stemming from implementation details).

My point is if you want to play in a walled garden with all the necessary pre-arrangement this implies, the solution is trivial.  But S/MIME is solving a more general problem:  i.e., secure communication with a *minimum* of pre-arrangement (specifically, S/MIME requires a single pre-arrangement message, communicating only the sender's certificate).  I have not seen any system *that attacks the same problem* and does better.

If people are concerned about privacy of the address, then stop using email.  I don't know what's expected here.  Mail systems (including snail mail) can't work by magic; the postman can't glean your intent direct from your mind.  *You have to write it on the damn envelope.*

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 26 Apr 2011 08:56:11 -0400

No offense, Ed, but walled garden systems are a dime a dozen and trivial.  I don't consider these to be a solution to the base problem of *two* communicating partners (walled garden systems have *three* partners--sender, recipient, and keyserver).  See my response to Stefan for more.

-- T

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Apr 2011 15:29:40 +0200

Timothy,

You are absolutely right,

However, in the world of identity federation, we often have almost all the
pre arrangements already in place.
If you already have a system in place for identification/authentication,
all you need is to set up a key server as an SP and you are practically
done.

And that is what I think is key, to leverage existing infrastructures to
make other problems easier to solve.

Bare S/MIME has it's place, but I can't see it being overly successful in
large communities that need e-mail encryption.

/Stefan

On 11-04-26 2:52 PM, "Miller, Timothy J." <[email-masked]> wrote:

>That's nothing more than a walled garden email system; there are hundreds
>of these out there (look around the HIPAA compliance space) and really
>aren't any great shakes.
>
>I could go on if I tried harder.  MS IRM is no different (and has a
>couple additional problems, mostly stemming from implementation details).
>
>My point is if you want to play in a walled garden with all the necessary
>pre-arrangement this implies, the solution is trivial.  But S/MIME is
>solving a more general problem:  i.e., secure communication with a
>*minimum* of pre-arrangement (specifically, S/MIME requires a single
>pre-arrangement message, communicating only the sender's certificate).  I
>have not seen any system *that attacks the same problem* and does better.
>
>If people are concerned about privacy of the address, then stop using
>email.  I don't know what's expected here.  Mail systems (including snail
>mail) can't work by magic; the postman can't glean your intent direct
>from your mind.  *You have to write it on the damn envelope.*
>
>-- T
>
>
>
>>>> sender, who is the party at risk, finds herself in the awkward
>>>>position
>>>> of having

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 26 Apr 2011 09:42:10 -0400

> all you need is to set up a key server as an SP and you are practically

Email is more general still.  MITRE and AAA-SEC have no prior arrangements, yet I can send you secure email *if* I can associate a key with you.  *How* I associate a key with you is open for discussion.  This may use a prior arrangement (you send me a signed email) or I may be able to discover it (via a directory, web reference, or email archive) on my own.

> make other problems easier to solve.

That's fine for intranet and E2E, but everyone else is left hanging.  While I'm sympathetic to intranet & E2E environments, it's not particularly hard to build directories in either, and a simple directory *does* solve the problem.  As a result I tend to think inventing new protocols to cover this special case is a waste of time.

-- T

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Apr 2011 16:00:10 +0200

On 11-04-26 3:42 PM, "Miller, Timothy J." <[email-masked]> wrote:

>Email is more general still.  MITRE and AAA-SEC have no prior
>arrangements, yet I can send you secure email *if* I can associate a key
>with you.  *How* I associate a key with you is open for discussion.  This
>may use a prior arrangement (you send me a signed email) or I may be able
>to discover it (via a directory, web reference, or email archive) on my
>own.

It may actually not be that far away. The EU stork project has built an
international model for identity federation across countries. If we both
have means of identification inside our respective international
infrastructure, that trust can be proxied cross borders.

In the planned swedish identity federation it would be even easier. In the
large international University community, this is all in place. The point
is that infrastructures capable of doing identification are emerging. At
some point there may be situations where you want to leverage that for
other things, such as secure e-mail.

Many other countries cross Europe has national identity federation
solutions in various stages of maturity.

>That's fine for intranet and E2E, but everyone else is left hanging.
>While I'm sympathetic to intranet & E2E environments, it's not
>particularly hard to build directories in either, and a simple directory
>*does* solve the problem.  As a result I tend to think inventing new
>protocols to cover this special case is a waste of time.

On the very contrary, leveraging large scale identity federation
communities is a solution for national and international relationships.
This is where identity federation beats direct trust in user certificates
by magnitudes. It's all out there happening right now.

/Stefan

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Tue, 26 Apr 2011 07:53:49 -0700

On 4/26/2011 5:56 AM, Miller, Timothy J. wrote:
> I don't consider these to be a solution to the base problem of *two* communicating partners (walled garden systems have *three* partners--sender, recipient, and keyserver).

Actually, to induce trust (reliance on information) you need to have at least 
_four_ parties to start (*).  What you call a "walled garden" is not enough to 
start. There is also no need for the third-party to be a key-server -- as the 
key can be computed by the parties in the dialogue (PKI, PGP, the zsentry 
system I mentioned).

For example, in secure PKI implementations you find the four parties as the two 
parties in dialogue, the CA and a verifier. The CA is not a key-server. If you 
only have the same CA as both the trusted introducer and the trusted witness 
(verifier), or if they are not independent from each other and the parties in 
dialogue, then you will find certain failure modes that may not be detected by 
at least one of the parties (even if no collusion exists) versus a 4-party 
implementation.

After you start, and trust has been verified to the the level desired by the 
two parties in dialogue, then the other two parties are no longer needed (the 
zsentry system).  You can also operate PKI in this way, transitioning to a 
non-PKI system after you start (this also helps improve signal security).

Cheers,
Ed Gerck

(*) You need to have /at least/ four parties to induce trust between two 
parties who have no pre-existing trust: the two parties in dialogue plus a 
trusted introducer and a trusted witness.  The latter is absent in (standard) 
PGP but can be provided in PKI.  The last two parties should be as independent 
as possible from each other and any other party.  If you only have two parties 
to start, a secure solution depends on pre-existing trust. If you only have 
three parties to start, or if the last two parties are not independent, a 
secure solution also depends on pre-existing trust. For higher assurance, you 
can add more parties than four. Reference: the link I sent before.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 26 Apr 2011 11:04:00 -0400

Does large-scale identity federation solve any privacy concerns?  In
other words, given your name or other information about you, can I look
up your email address?

Given your email address, I can either:
1) look up your public key, or
2) look up your TTP's address, create a private key, and deposit it with
the TTP for you to retrieve

Whether or not the lookups use the LDAP protocol, the "identity
federation" performs the function of a directory.  And if the wall
around the garden is large enough, it becomes "The Directory".

So I've lost the bubble on the privacy concern - you may let only a
defined community look up your email address and cert or TTP, or you may
let everyone look them up.  But as far as I know, there is no
implementable policy that would let "everyone but spammers" look you up
and send you encrypted email.

Dave

-----Original Message-----
Stefan Santesson

On the very contrary, leveraging large scale identity federation
communities is a solution for national and international relationships.
This is where identity federation beats direct trust in user
certificates
by magnitudes. It's all out there happening right now.

/Stefan

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 26 Apr 2011 18:24:43 +0000

By your definition - pki is a series of walled gardens. How many times do we see signed email we are unable to validate? So the walled garden argument is just as applicable to S/MIME today.

Technology alone is not going to solve the walled garden problem. It's going to be a combination of technology and policy. We need a better defined set of rules for establishing subject identity and attributes so we can more readily understand what is presented is acceptable.  When I hire a car in Europe, I don't need to present a European driver's license. I present a license which is deemed to have been issued under an agreed set of minimal standards. There is a form or trust framework in place.

The objective of Plasma is to enable policy enforcement in addition to confidentiality. In many situations knowing the recipients public key is not enough. You need to know more attributes about the recipient in order to determine if they can see the content of the message. The sender does not typically have access to that wealth of information and it's unreasonable to expect it. A recipient needs to provide consent to the release of that information. The TTP provides a mechanism for the recipient to present the necessary attributes under their control.

Plasma also looks to decouple the type of credential a recipient has from the protocol so we don't have to require the entire universe of recipients to have been enrolled in PKI at the time you send a message. Still waiting to that to happen:). We need a level of assurance of identity but there are many forms of credentials which can be used and as long as it's good enough, I don't care what is used.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, April 26, 2011 6:42 AM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: [pkix] Email in Certs and Privacy Concerns

On Apr 26, 2011, at 8:29 AM, Stefan Santesson wrote:

> However, in the world of identity federation, we often have almost all

> the pre arrangements already in place.

> If you already have a system in place for

> identification/authentication, all you need is to set up a key server

> as an SP and you are practically done.

> And that is what I think is key, to leverage existing infrastructures

> to make other problems easier to solve.

-- T

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 27 Apr 2011 01:40:01 -0400

Hi List,

when I posted the message I was trying to draw the attention to the
fact that, even if in theory, email is not a concern for privacy, in
practice CAs treat this field as if there were privacy issues.

The current situation is that CAs don't publish certs in public
directories.

A simple solution would be to get rid of the email field. The problem
is that many (if not all) email programs rely on that field in the
certificate for certificate lookup (especially for sending encrypted
emails). Also, by putting the email field in the cert, it allows CAs
to "declare" which email addresses have been verified (for example,
look at free email certs providers) by them (verifiable name space).

The solution of having a somehow-hashed version of the email address
in the certificate would solve this issue-non-issue and allow CAs to
publish certs more easily without requiring to rely on any TTP and/or
changing the whole S/MIME standards.

Maybe we could agree on an extension in the certificate that implements
the hashed version of the email and we could call it something like
verifiedEmailAddresses.

Just a thought: I am trying to propose a solution targeted to solve a
specific issue we face today in the real world.

I would like to hear the opinion of someone who works/manages internet-
oriented CAs/PKIs (if there are on this list...)

Cheers,
Max

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Apr 2011 09:23:53 +0100

On 27 Apr 2011, at 06:40, Massimiliano Pala <[email-masked]> wrote:

> A simple solution would be to get rid of the email field.

What evidence do you have a) that the first thing is a real problem and b) that the second thing is even a solution at all?

I think you're maybe making a bunch of unwarranted assumptions, when you go ahead and discuss mechanism here.

S.

> The problem

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 27 Apr 2011 20:34:49 +1200

Massimiliano Pala <[email-masked]> writes:

>The current situation is that CAs don't publish certs in public directories.

This is because there aren't any public directories to publish them in, not
because of any privacy concerns.

>A simple solution would be to get rid of the email field.

We should also add a pink elephant extension to certs, maybe that's another
reason why CAs aren't publishing them in directories.

>I am trying to propose a solution targeted to solve a specific issue we face
>today in the real world.

The issue we face is that there isn't anywhere to publish certs.  No amount of
email address hashing or pink elephants is going to fix that.

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 27 Apr 2011 08:22:26 -0400

For some reason Flickr hasn't found a way to monetize cert storage,
Google /Bing have not found a way to monetize cert searches, and
Facebook customers haven't asked for better login security.
Unfortunately, despite the inconvenience resulting from the Playstation
breach, users still aren't likely to demand it.

But if Yahoo offered "generate cert" and "use existing cert" buttons
beside the "pick a password" strength meter on the registration page,
users might find PKI more convenient than the alternative.

If Max wants certs published, he should be lobbying social media to make
it easy, not PKIX to make it harder.

Dave

-----Original Message-----
From: Peter Gutmann
>
> The issue we face is that there isn't anywhere to
> publish certs.  No amount of email address hashing or
> pink elephants is going to fix that.
>
> Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Apr 2011 15:29:27 +0200

> it easy, not PKIX to make it harder.

Agreed.  Why social media won't buy into this is because there is
no working "generate cert" client solution worth mentioning.

-- Anders

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 27 Apr 2011 11:04:01 -0400

On 04/27/2011 04:23 AM, Stephen Farrell wrote:
[...]
> second thing is even a solution at all?

As a PKI practitioner and researcher, I face the certificate availability
problem all the time. This issue is quite a problem when it comes to the
email environment where, as you know, email encryption is still hard to
achieve.

I was just trying to point out a problem that many PKI operators (e.g.,
universities or private companies) have told me about. Unfortunately I
don't have statistics on that. I might just thought I would point out
the issue in the list and see if there was anybody who was facing the
same issues.

It seems not, so I think there is no point in continuing the thread in
this list.

Just last thought, (a) also other people pointed out that the spam/email
collecting is potentially an issue, and, just to be clear (b) I never said
that what I proposed *is the solution* but a 2-mins idea that could start
a discussion about the issue.

Cheers,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 27 Apr 2011 11:06:26 -0400

On 04/27/2011 04:34 AM, Peter Gutmann wrote:
> Massimiliano Pala<[email-masked]>  writes:
>
> This is because there aren't any public directories to publish them in, not because of
> any privacy concerns.

I might disagree with that. There are many organizations that have publicly
accessible directories.

[...]
> We should also add a pink elephant extension to certs, maybe that's another reason why
> CAs aren't publishing them in directories.
[...]
> The issue we face is that there isn't anywhere to publish certs.  No amount of email
> address hashing or pink elephants is going to fix that.

Although I do really like pink elephants... I agree that's not a solution.

Thanks for the feedback anyway.

Cheers,
Max

---

From: Stephen Wilson <[email-masked]>
Date: Thu, 28 Apr 2011 03:50:10 +1000

> because of any privacy concerns.
I disagree, and I am surprised that Max is not getting more traction on 
the list for this issue.  I have plenty of clients in Australia building 
enterprise PKIs who are very reluctant to publish certificates and CRLs 
on any publicly accessible directory.  They fear the certs will be 
trawled by spammers, and they recognise CRLs are private because they 
often contain personal information suggestive of employment matters like 
implied reasons for terminating employment.

In closed communities where the certificates are typically consumed by 
special purpose applications, an access-controlled directory is usually 
preferable.

This is the *general* case that standards bodies should consider. As I 
have tried to stress previously, the open public e-mail oriented PKI is 
a *special* case, and not especially interesting based on its miserable 
track record in the market.

Cheers,

Steve Wilson

Lockstep
http://lockstep.com.au <http://www.lockstep.com.au>
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 27 Apr 2011 20:42:12 -0400

On Apr 27, 2011, at 12:50 PM, Stephen Wilson wrote:

> I disagree, and I am surprised that Max is not getting more traction on the list for this issue.  I have plenty of clients in Australia building enterprise PKIs who are very reluctant to publish certificates and CRLs on any publicly accessible directory.  They fear the certs will be trawled by spammers, and they recognise CRLs are private because they often contain personal information suggestive of employment matters like implied reasons for terminating employment.

Yet they'll use those same email addresses to communicate with outside partners--they'll email anyone at all, actually--and use mailing lists, forums, or websites that require email registration.  All of which can be trawled by spammers (or even *sold* to spammers for profit).  You'll pardon me if I'm unsympathetic.

And since reason codes are optional in CRLs, I fail to see a coherent objection to publishing CRLs in an accessible location.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 28 Apr 2011 10:30:53 -0400

There is a qualitative difference between "give me the email addresses
of all company employees" and "give me the email address of this
employee".  You can have a public web server with no access controls,
but unless you already have links you can't get to the content without
exhaustively searching the URL space.

Max, in proposing that emails be hashed in certs, assumed that spammers
already can trawl every cert published by the company.  Why wouldn't it
be better to publish all the certs, but only to someone who already
knows what the cert contains.  The index must be sparse - if the query
is by Issuer / Serial Number you don't want to number the certs from 1
to N, the serial number should be unguessable like a 16 byte random
value.

Or, if you assume that email addresses are unguessable enough to make
hashing useful, then just use email address as the search index without
hashing.  How could a spammer harvest all the certs without already
knowing all the email addresses?

In other words, what is the problem these Enterprise PKIs are trying to
solve by not publishing certs or CRLs, and why can't it be solved
instead by changing how they are published?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miller, Timothy J.
Sent: Wednesday, April 27, 2011 8:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Email in Certs and Privacy Concerns

On Apr 27, 2011, at 12:50 PM, Stephen Wilson wrote:

> I disagree, and I am surprised that Max is not getting more traction
on the list for this issue.  I have plenty of clients in Australia
building enterprise PKIs who are very reluctant to publish certificates
and CRLs on any publicly accessible directory.  They fear the certs will
be trawled by spammers, and they recognise CRLs are private because they
often contain personal information suggestive of employment matters like
implied reasons for terminating employment.

Yet they'll use those same email addresses to communicate with outside
partners--they'll email anyone at all, actually--and use mailing lists,
forums, or websites that require email registration.  All of which can
be trawled by spammers (or even *sold* to spammers for profit).  You'll
pardon me if I'm unsympathetic.

And since reason codes are optional in CRLs, I fail to see a coherent
objection to publishing CRLs in an accessible location.

-- T

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Apr 2011 08:53:03 +0200

>reason why CAs aren't publishing them in directories.

This makes me excited... You may be onto something big here!

>email address hashing or pink elephants is going to fix that.

WHAT!  Pink elephant extensions does not work either.... What a shame.

Well, I can make a repository of certs, and I could make it public in
minutes.
I think that even if we could, we would not do it, because it is backwards
and inefficient to let systems lookup end-user certs. It's only applicable
to store and forward systems, and even there it is kind of backwards,
especially when broadcasting information to a larger group. It obviously
only works in tightly managed communities, and for that use-case I don't
se a privacy issue.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Apr 2011 09:35:57 +0200

On 2011-04-29 08:53, Stefan Santesson wrote:
<snip>

> only works in tightly managed communities, and for that use-case I don't

IMO the real issue is: What is the alternative to S/MIME?

I and some 500M other users depend on Skype which gives end-to-end
security as default and have proved to work for non-techies as well.

The reliance on a single provider is of course a snag but
since the e-mail people screw up e-mail security by downplaying
the domain/server-level alternative (which had worked for > 90%
of all legitimate use-cases), this is essentially what we got.

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Apr 2011 10:31:08 +0200

>IMO the real issue is: What is the alternative to S/MIME?

I agree,

I think the alternative to S/MIME is more like a complementary way to use
S/MIME and that is not to encrypt the mail using the recipient's public
key, but to encrypt it with a key that the user can retrieve by some kind
of "I authenticate to receive the key" procedure.

This would also be a golden opportunity to marry secure e-mail with
identity federation techniques for authentication. And the latter has
proven to be hugely successful simply because it allows users to live in a
"walled garden", but still authenticate to services outside of it.

Plasma could be a great step in that direction.

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 29 Apr 2011 23:40:07 +1200

>IMO the real issue is: What is the alternative to S/MIME?

STARTTLS.  From a (very informal) survey I did about a year after it was
deployed, it was protecting more email in its first year than every store-and-
forward email encryption protocol combined after a decade of use.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 30 Apr 2011 00:31:41 +1200

Stephen Wilson <[email-masked]> writes:

>I have plenty of clients in Australia building enterprise PKIs who are very
>reluctant to publish certificates and CRLs on any publicly accessible
>directory.  They fear the certs will be trawled by spammers, and they
>recognise CRLs are private because they often contain personal information
>suggestive of employment matters like implied reasons for terminating
>employment.

So what you're facing here is a user perception problem rather than a real 
risk, from people who (I'm guessing) have very little to no of idea how the 
spam industry works.  We know from anti-spam researchers that spam brokers 
don't even bother de-obfuscating the common 'name AT domain' address-hiding 
used in public web sites, blog posts, and so on, because they already have 
large databases of high-quality verified email account names and related 
metadata from vendor compromises (think events like Epsilon, or more generally 
do a search for "database compromised email address", which currently returns 
10M hits).  The chances of a spam broker looking around for undocumented 
certificate databases on the net, figuring out which DAP/LDAP voodoo they need 
to use to walk the database, extracting the certs, and pulling out the email 
addresses, is zero given that they don't even feel the need to convert 'AT' to 
'@' for a free address harvest.

So what you have is purely a user perception problem, for which you can tell 
them that you have multiple levels of security in place to prevent harvesting 
(running LDAP is enough to scare anyone off, and putting things inside certs 
will stop the small percentage of truly insane people who do get that far, so 
that's multiple levels of security).

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Apr 2011 14:46:38 +0200

> forward email encryption protocol combined after a decade of use.

100% Agreed.  The problem as I see it is that STARTTLS and mail
clients seem to live in separete worlds.  If this had been properly
architected you should get a warning

  "This message will be sent in clear, do you want to send it anyway?"

if there was no STARTTLS support in the other end.

In addition:

- STARTTLS hides the identity of the receiver and sender.

- STARTTLS enables efficient black-listing.

- STARTTLS is compliant with message content scanning.

IMNSHO, current e-mail (non) "security" is the result of major
over-selling of S/MIME as the "solution".

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 29 Apr 2011 10:40:31 -0400

Skype and S/MIME aren't comparable.  Skype is a single system; S/MIME is not--every mail system is independent of all others.  Skype is also synchronous (mostly), S/MIME is entirely asynchronous.

These are completely different problem domains.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 29 Apr 2011 10:42:58 -0400

IMHO gateway-signed S/MIME makes more sense.  An organization attestation of "This message came from X" is nearly as good as the individual's assertion.

If you want federation-like capabilities, this is probably as close as you get.

-- T

---

From: "martijn.list" <[email-masked]>
Date: Fri, 29 Apr 2011 16:45:33 +0200

> - STARTTLS is compliant with message content scanning.

Although STARTTLS has it's merits, it's not a real substitute for
encrypting the message content with S/MIME or PGP. TLS only protects the
channel not the message. You can enforce TLS only for the first SMTP
hop, you can only hope that the next hops will use TLS as well but there
is absolutely no guarantee.

> over-selling of S/MIME as the "solution".

Same thing can be said about TLS since it only gives you a false sense
of (real) security.

Kind regards,

Martijn Brinkers

-- 
Djigzo open source email encryption

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 29 Apr 2011 22:22:05 +0200

On 2011-04-29 16:42, Miller, Timothy J. wrote:
> IMHO gateway-signed S/MIME makes more sense.  An organization
> attestation of "This message came from X" is nearly as good as
> the individual's assertion.

I personally advocated such solutions over a decade ago (!) in this
very list and essentially everybody thought "server-based security"
was an altogether bad idea.  Now it is too late to [really] secure
e-mail and the S/MIME group has closed.  Skype won on "walk-over".

Today PKCS #10 is claimed to be the "solution" for PKI provisioning
in spite of the fact that:
- PKCS #10 only addresses a tiny fraction of the actual process
- XML (unlike ASN.1) is natively supported by Java and .NET
- End-to-end security provisioning is piece if cake

Just another obvious security train-wreck in the workings.

Anders