Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed?

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 01 July 2016 16:49 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91112B069 for <openpgp@ietfa.amsl.com>; Fri, 1 Jul 2016 09:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0I8kbI-yhsU for <openpgp@ietfa.amsl.com>; Fri, 1 Jul 2016 09:49:00 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E812D647 for <openpgp@ietf.org>; Fri, 1 Jul 2016 09:49:00 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id e3so9462195qkd.0 for <openpgp@ietf.org>; Fri, 01 Jul 2016 09:49:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vBVib186OdNL0Mu8IAr9dCzFT79Rw7Vjr46oLJTMqm8=; b=BQXFkFbciKsJTdOU737ZzCZuibr3lgjs4EtN2W2S/R8mMD9HM/BoTzpDCzS34CuwyC NEjmXYaL7NJ/EgTe52cWzIIh6XygI2kGm+AqTx+6cP8YN8UIU3zSmkTR2UCPAWBQVsTd T9IP/DEhuzCgJk9ovosom9DevIJRQ5H3gQINd/+XXlqMjIPTAiAPGgaC/8b2+/kFFWTi SmEJ+fsQYkOeYEgkLTJLq0nn0L3aCtA8R0pauUkbz8VgBpaWfdEY68q0OoBXotOGahrt 1so0vMpIyqUaBI1MSpTw5SwZkwPSoMsS8l+MJIZCznqg4Qa6C+8CvpK3EaCQnUW5KV5/ S3cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vBVib186OdNL0Mu8IAr9dCzFT79Rw7Vjr46oLJTMqm8=; b=AoGhmeaa8Gzluwp5zhBCViL6t3B7io9Z+MHX0fFfM/sLWJPEHEhT5WwV023mIN9lTN ZzRKgZfyNnXBoyTvX39ZGHD5LLujSypfsKHkMIs3iAXGpcCf6xrLuco4yn/G9AnyCUaU ilr1nzaMMMcXiz8UoLx46wnw2w9MpTq4k54kNOe3Vxmwua7c/4wHI6tP66uhw9qww3xG IVQvV3tE93cHo3p8i4xhUmZKv/pnfwmn3kBBiuyTW+7cj86iutGBmL5RnPLQ06M7+Q+H qdCkLnX94YCg7DBaNL9Gm0OuSxPe5uQTnzwl5wfQGREIZXee/29OKTSmWgrFDvH0mIwN 1UXg==
X-Gm-Message-State: ALyK8tJz/SmEeWVg8BpUvzL/XAfl9hQM5j43EmCufuAVw0zXajgJcrEA9vQVjZ8VrEHsER3gaXIvJY+wxVBAXw==
X-Received: by 10.55.159.72 with SMTP id i69mr26805037qke.29.1467391739509; Fri, 01 Jul 2016 09:48:59 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.55.16.106 with HTTP; Fri, 1 Jul 2016 09:48:58 -0700 (PDT)
In-Reply-To: <sjmwpl5qtqy.fsf@securerf.ihtfp.org>
References: <20160701153304.332d2c95@pc1> <sjmwpl5qtqy.fsf@securerf.ihtfp.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 1 Jul 2016 12:48:58 -0400
X-Google-Sender-Auth: GE_OMD65gXf_wu9G0OrvZbNDqyg
Message-ID: <CAMm+LwjGZeZTpUjOp_McDrp6cMQQn=Sy6Wp+Ti5M--V4vnMDqw@mail.gmail.com>
To: Derek Atkins <derek@ihtfp.com>
Content-Type: multipart/alternative; boundary=94eb2c06b730614329053695c3de
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/9-Nlf0_DaD5q045tsXShmuZy6b0>
Cc: IETF OpenPGP <openpgp@ietf.org>, =?UTF-8?Q?Hanno_B=C3=B6ck?= <hanno@hboeck.de>
Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 16:49:04 -0000

I have wanted this for a long time. there are actually three separate
problems to be solved.

1) How to make S/MIME work with OpenPGP credentials

2) How to make OpenPGP work with S/MIME credentials

3) How to merge the two specifications into one.

The conditions for making the first two happen are easy. If there is a
will, IETF will find a way. We already have an OpenPGP group. The
chartering of a SPASM group is in the works. I do not think it is going to
be at all difficult to get ADs or IESG to approve work to make two existing
IETF standards interoperate. That is what IETF is for.

The third is still hard because it requires existing infrastructures to
merge and that is a long and difficult process unless you can deliver a
major improvement in functionality. I just can't see merger of two email
security standards offering encryption and signature into one offering that
incentive.


But that doesn't have to be what we do. I think we do have an option that
would be Blu-Ray to OpenPGP and S/MIME's Betamax and VHS. There are in fact
three technologies we can build on that offer dramatic improvements in
functionality.

1) Linked Timestamp (aka Blockchain)

Forget Bitcoin for a minute and proof of work. Linked Timestamps improve
the Work Factor of any PKI and you do not in fact need proof of work to
guarantee that. There are better, cheaper options to achieve the same
result.

Let us imagine for a moment that we upgraded the MIT Key Server
infrastructure that supports OpenPGP to a similar infrastructure that
included technology similar to Certificate Transparency. As soon as a key
signing or certificate or whatever is enrolled and the infrastructure
synchronizes, the Work Factor for backdating a forgery of that assertion to
before the enrollment date goes to 2^256. That is real cryptographic power.

2) Combining the Web of Trust and Brokered Trust (CA) models

People have fixed on the idea of one model or the other. What if we choose
both. The work factor of the resulting Webs of trust becomes very high very
quickly and more importantly the work factor values become objective.

3) Proxy Re-Encryption

[NB IPR encumbrance for the next 18 months]

Using Recryption, a user can encrypt a document to be read by a named group
of users (e.g. secretgroup@example.com) using the public key for that group
and upload it to a server. The server can then create decryption keys for
each of the users that have been granted access by the administrator by
converting the decryption blob for the group into a decryption blob for
each authorized recipient. But the server can't decrypt the document itself.

Recryption is very very powerful and we should make it the heart and soul
of the next generation of message security infrastructure.

* Chat rooms which can only be accessed by people who are on the list
   *These can be text, voice, video, naturally
* Dropbox style document repositories
* Next generation email
* Internal document distribution.

Recryption offers real power and we have been ignoring it for too long.


Now a program of the type I am describing is obviously not something for
SPASM or OpenPGP to discuss. It is way beyond their charter. In fact some
folk will probably argue that this is IRTF work, not IETF.

But I do have the start of open source (MIT license) code for a system that
I believe could grow into this. And the code is almost on the verge of
working cross platform. It uses all the modern platforms you would expect,
JSON over HTTPS, consensus crypto algorithms, etc. etc.

I am trying to follow the path that Tim laid out for the deployment of the
Web - start off by concentrating on how to add value to existing code
bases. The early Web users weren't actually using HTTP very much. Most of
the information they were getting came from FTP, NNTP, WAIS and so on. The
main use of HTTP and HTML was to provide a common interchange format for
gateways to access legacy gateways.

So right now, all the Mathematical Mesh is focused on is making S/MIME and
OpenPGP and SSH and Web Usernames/Passwords easy to use. I am working to
make existing crypto applications as easy to use as legacy ones. This isn't
'OK usability' meaning follow a long list of instructions. As you all know,
I am an obsessive and a perfectionist when it comes to usability. This is
security that you won't know is there unless you are asking yourself if
something is safe and start looking into it.

But if the Mesh succeeds then we get to a point where a significant
userbase has private keys established on every single device they use. We
have a large client side PKI that can establish trust through Web of Trust,
PKI or hybrid methods. Once you have that in place, developing new
cryptographic applications to leverage that infrastructure is really
straightforward.


I could use some help.