Subject: [smime] S/MIME publishing mailing list

From: Michael Ströder <[email-masked]>
Date: Fri, 23 Jan 2015 10:59:23 +0100

HI!

Still getting S/MIME certs of other mail users is a unsolved problem.

Would it make sense if the IETF would simply host a non-WG mailing list for
simply publishing S/MIME certs via e-mail?

So if mailing list members get a new S/MIME cert they send a signed e-mail
with almost empty content to the mailing list and all subscribers get the
certs and S/MIME capabilities.

Ciao, Michael.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 23 Jan 2015 07:21:44 -0500

Great idea.  Better yet, produce a RFC
for S/MIME cert exchanges based on the
idea.

On 2015-01-23 4:59 AM, Michael Ströder wrote:
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Jan 2015 08:16:13 -0500

On Fri, Jan 23, 2015 at 7:21 AM, Tony Rutkowski <[email-masked]> wrote:

> I am working on code for something very similar.

Right now we have two IETF projects, TRANS and ACME that might have a lot
of bearing on filling in the gaps in SMIME.

ACME is not yet a WG, the initial proposal is limited to TLS certs but if
the protocol is properly designed it could fix the problem as follows:

* Some JSON based web service allows an email client to register certs and
encrypted private keys with a service. This might be a locally run service
or a TTP service (aka CA).

* The service registers the certs in a TRANS log just for certs.

* We use a globally unique key identifier formed from the hash of the
KeyInfo block as a locator / PGP type fingerprint.

* Location services search any public TRANS log.

I almost have code complete. See prismproof.org for details, specs, code,
etc.

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jan 2015 10:11:33 -0500

The IETF Enroll WG was chartered to solve this problem, but it folded before doing so.

http://datatracker.ietf.org/wg/enroll/charter/

We could get the ietf-enroll mail list reactivated if there is interest.

Russ

---

From: Michael Ströder <[email-masked]>
Date: Fri, 23 Jan 2015 18:19:59 +0100

> We could get the ietf-enroll mail list reactivated if there is interest.

I think I have to clarify:

My suggestion was not about cert enrollment. I also don't want to invent a new
mechanism. I just thought of a very *simple* S/MIME cert publication tool in
form of a mass subscriber mailing list. *Existing* standard MUAs could
immediately leverage importing S/MIME certs from signed messages sent to the list.

Even though the ietf-enroll charter sounds interesting it does not seem
appropriate to reactivate the mailing list for the purpose I described.

But maybe reviving ietf-enroll WG would be interesting.

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jan 2015 12:28:52 -0500

> appropriate to reactivate the mailing list for the purpose I described.

We need to make it easier to get certificates, and then we need to make it easier for others to find those certificates.  I'm willing to work on both of these.

Russ

---

From: Michael Ströder <[email-masked]>
Date: Fri, 23 Jan 2015 18:31:55 +0100

Russ Housley wrote:
> We need to make it easier to get certificates, and then we need to make it
> easier for others to find those certificates.

Yes. But it's not a hard requirement that we have to proceed in exactly this
order.

> I'm willing to work on both of these.

So there are already two of us. :-)

Ciao, Michael.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 23 Jan 2015 17:42:43 +0000

We could build one big honkin' directory... :)

Personally I think there's more than enough ways discover and transfer
certs.   

The gap, in my mind, is the introduction problem--if you and I have never
corresponded securely before, how do I know that the cert I have is yours?

-- T

On 1/23/15, 11:28 AM, "Russ Housley" <[email-masked]> wrote:

>We need to make it easier to get certificates, and then we need to make
>it easier for others to find those certificates.  I'm willing to work on
>both of these.
>
>Russ
>

---

From: Michael Ströder <[email-masked]>
Date: Fri, 23 Jan 2015 19:03:51 +0100

> We could build one big honkin' directory... :)

Yes. :-)
But with an e-mail process in front of it.

> Personally I think there's more than enough ways discover and transfer

The problem is that there are so many ways normal end users have to know about
to get access to only partial space of S/MIME certs.

> corresponded securely before, how do I know that the cert I have is yours?

Yes, basically that's the enrollment problem. It's a separate problem, and
much harder of course.

Ciao, Michael.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jan 2015 10:45:38 -0800

Having a place where everyone sends signed mail with their certificate is a bad idea: people will think that it is a good source of certificates, which it is not.

Having said that, a service that receives an email, a human vets it slightly, and then there is a round-trip test that the purported sender can receive mail at that address and respond to it, seems reasonable. It would just as well for OpenPGP. Someone who trusts that the service is adequately run could use it to get certs, and maybe even tell people to use.

I'm not volunteering to design or write this, but would be willing to kibbitz on drafts.

There is recent precedence for such a service: see <https://keybase.io>. I'm "paulehoffman" on that service, and have two invites left if folks are interested. It is a bigger picture than what is being proposed here, and is having birthing pains, but so far seems useful.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Jan 2015 14:08:08 -0500

> We could get the ietf-enroll mail list reactivated if there is interest.

That is one approach. But I think the problem is a bit bigger than certs
and that we should try to share as much of the ACME work as possible.

What I am trying to do with PRISMProof is to

1) Make using S/MIME as easy and transparent as using regular mail.
2) End the trust model wars by enabling a trust model agnostic approach.

One consequence of (1) is that in the days where we all have multiple email
devices, we need to be able to read our mail on any one of them. That means
that the only feasible model is one in which we have one decryption key per
role that is shared across all the devices permitted to read mail in that
role.

Fortunately a direct consequence of (1) is that all the processes have to
be automated so that there is no user interaction except when initially
setting up a personal hierarchy and when attacking a device to it as
authorized to receive mail. That means that rotating the encryption key on
a weekly basis is quite practical. Provided that is, the trust model is
bound to a more permanent key.

So what I have working now is a command line program that when run will
automatically configure Windows Livemail (aka Outlook Express) to use
S/MIME. It would be easy to support other clients, that is just the one I
started with.

The only user parameter is an optional parameter for an external CA. By
default, self signed certs are generated. The next step is to hook them up
to a CA. Comodo has a free cert for S/MIME program and an API which is a
logical starting point. But the API is not JSON and it makes more sense to
have a single web service for S/MIME and TLS which I hope ACME will take
note of.

At the moment all messages go over HTTP. I see no advantage to using SMTP
for the purpose of managing certs and private keys. I am not aware of any
modern Internet device that is not capable of doing HTTP. Why make things
hard?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Jan 2015 14:15:17 -0500

On Fri, Jan 23, 2015 at 1:45 PM, Paul Hoffman <[email-masked]> wrote:

> Having a place where everyone sends signed mail with their certificate is
> a bad idea: people will think that it is a good source of certificates,
> which it is not.
>
> Having said that, a service that receives an email, a human vets it
> slightly, and then there is a round-trip test that the purported sender can
> receive mail at that address and respond to it, seems reasonable. It would
> just as well for OpenPGP. Someone who trusts that the service is adequately
> run could use it to get certs, and maybe even tell people to use.
>

+1

What you describe is a CA in that it issues certs. Much better to have a
low fidelity CA than no CA at all.

Comodo is currently providing free S/MIME certs to individuals which is
inside the PKIX model.

For private individuals giving certifications, I would prefer to move
outside the PKIX syntax and define a new structure, an 'endorsement'. There
is no value to doing that in ASN.1 and we don't want to do path math or
chain construction on them.  But they are incredibly valuable.

> There is recent precedence for such a service: see <https://keybase.io>.
> I'm "paulehoffman" on that service, and have two invites left if folks are
> interested. It is a bigger picture than what is being proposed here, and is
> having birthing pains, but so far seems useful.
>

One bit of missing glue is whether a recipient prefers to receive encrypted
mail. Right now I only have some of my mail clients supporting S/MIME and
so I really don't want encrypted mail unless it is important that it be
confidential.

Reading encrypted mail on a webmail interface is not too difficult, its
just a different media reader. Authoring is harder.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jan 2015 11:20:20 -0800

On Jan 23, 2015, at 11:15 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> What you describe is a CA in that it issues certs.

...and also has a directory of the issued certs.

> Much better to have a low fidelity CA than no CA at all.

Definitely. Maybe DANE will be a solution, but there is very little energy there.

> Comodo is currently providing free S/MIME certs to individuals which is inside the PKIX model.

So is StartSSL. However, the problem that Michael would then have is how many places he should look for a cert for [email-masked]. And what to do if he sees two overlapping but disagreeing certs when he looks in multiple places. Nothing new here.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Jan 2015 14:25:44 -0500

On Fri, Jan 23, 2015 at 2:20 PM, Paul Hoffman <[email-masked]> wrote:

> So is StartSSL. However, the problem that Michael would then have is how
> many places he should look for a cert for [email-masked]. And what to do if
> he sees two overlapping but disagreeing certs when he looks in multiple
> places. Nothing new here.

Which is why I think we need TRANS type technology in the mix.

TRANS has a natural network effect. It is best to be in the big log. It is
easy to aggregate logs of public logs. Therefore there will be convergence
on a single public log that contains most of the data that matters.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 23 Jan 2015 21:36:17 +0100

> modern Internet device that is not capable of doing HTTP. Why make things

Call me old-fashioned. But still 100% of my sent and received e-mail messages
are transported over SMTP (on some connections even using STARTTLS). Trading
HTTP over SMTP does not gain anything.

While there may be whatever genious solution available in the future I'm
aiming to use S/MIME via SMTP with all its current drawbacks, because that's
what's widely implemented *now*.

I don't want to wait for yet another standard to be invented, reviewed, widely
implemented, discredited and abandoned in the next 20 years.

Folks are now using JSON instead of XML instead of ASN.1 (see the fatiguing
JSON-vs.-ASN.1 discussion, formerly seen as the fatiguing XML-vs.-ASN.1
debates). But the basic problems are still not solved not to speak of lack of
availability of mature implementations. :-(

Fail.

Ciao, Michael.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 Jan 2015 17:59:59 -0500

> HTTP over SMTP does not gain anything.

It gains a great deal of speed and removes many sources of instability and
unreliability. Rather than being limited to a single request/response it is
easy to make additional requests if warranted.

The SMTP email infrastructure is horrible to work with. There are corner
cases everywhere and a large number of servers have idiot ideas about
mangling messages.

> what's widely implemented *now*.

The objective is to distribute certs though, that is a problem HTTP is
already designed to support and SMTP is not.

---

From: Michael Ströder <[email-masked]>
Date: Sat, 24 Jan 2015 09:54:44 +0100

Phillip Hallam-Baker wrote:
> The SMTP email infrastructure is horrible to work with.

As said I don't want to wait another 20 years before encrypting e-mails with a
new shiny HTTP-based infrastructure.

> There are corner cases everywhere and a large number of servers have idiot
> ideas about mangling messages.

I'm pretty sure that it would take many years before all implementation issues
in corner cases are sorted out when switching to HTTP.

> already designed to support and SMTP is not.

???

All the S/MIME enabled MUAs take the S/MIME cert from a signed e-mail
including the S/MIME capabilities. And yes, I know how to distribute certs via
HTTP and that could be a second option.

Ciao, Michael.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 26 Jan 2015 13:57:43 +0000

> But with an e-mail process in front of it.

So if someone wants to run such a service altruistically, it'll suffer from lack of voluntary uptake.  

Alternatively, if someone wants to run such a service and make it required, it'll suffer from lack of a business model.

> to get access to only partial space of S/MIME certs.

The real problem is S/MIME is a solution looking for a problem.  

The first problem is that the generally perceived need for end-to-end email integrity and confidentiality outside corporate and government networks is low.  Most common use cases are primarily met by opportunistic TLS between MTAs, which is generally (though slowly) increasing (http://www.google.com/transparencyreport/saferemail/?hl=en) and not under the user's control.

The second problem is that in all environments normal end users don't know squat about cryptography and have an exceedingly hard time grappling with it.  As simple as S/MIME and certificates appear to us, to most users it's an impenetrable fog.  In the environments I support, we've had to resort to deploying MUA plugins to try to detect cases where integrity or confidentiality should be employed and prompt (or force) the user to comply.  These kinds of technological fixes to people problems are usually a good sign of failure.

-- T