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

Phillip Hallam-Baker <> Tue, 05 July 2016 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE2C312B032 for <>; Tue, 5 Jul 2016 16:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EpZSV0pDEHmL for <>; Tue, 5 Jul 2016 16:05:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75A0F12B02F for <>; Tue, 5 Jul 2016 16:05:22 -0700 (PDT)
Received: by with SMTP id c34so108726711qte.0 for <>; Tue, 05 Jul 2016 16:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7937uF2gdQ8YIirFq8gAODe2rBSAah32rX2vwIh+eHM=; b=DnduBmnG3UGu4Q6F2r+E32TyfbB8NkgVNOf3PbI+ePTkFBHMVOuaEP+faTr7M5spuH euXfZ+cTAOC1LWsZfVaraSQ6U+g4vsUKFxnp17b104pZBHeAzChbQkoFRYkU94bWtGJO NX9EarPXYi1pdx7SiQMbMY0qv4TblODaMCDs7Q092lrltpWhpUVjbOs28G9G4Q5kiDPx LSizTZnb8TPnVHJ2pYHuQKxXCCcnfE/ylpKbwUTZzZJEU6/IBr+WAbNO0jl1E0L0WERR IF6Wvc44BGJWwuLUQlgU5DKGj12E5sU9qXYLos2Xk+UXf2dBbHkZsir+lG+rMISv7PSd MB3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7937uF2gdQ8YIirFq8gAODe2rBSAah32rX2vwIh+eHM=; b=JIn8dtkvrbhWL1USqI1fExYS83Gbpgul73QITVhsEHFptVsdHFjXCQ1wMt9fLhvyVU GJawiBxjoxWTZNcyo3H/k8Rh+4F/glRNqn6QIigIqmlt5JJ8FS23vNMUtQkNWNnG/+BG HSSHSGqkifpo+Kj0nud9pFuv/vV3qrf4v8g3WitAMDjEbnKOc6CL6aQViBdh69KI/4aE HqPGWNh0Y1dtiCtlAA0Pj33BoO4QTsJyO0YkPuAkr3jb+MH1SJcpemgVs1KZOBRXcLz+ DUk58SWq61auYaiIiZO9I9nS//ZOpOxFIUGILZWSxW0Ztzv8bqPRNcoXcKl/x1X6AYA+ iyqw==
X-Gm-Message-State: ALyK8tJWm2CXTdoCBERjlQLDTNPwPIDdaUp4ug8olPU9rvSqLBHzVJ4FboUqGnIV7eIfAHNBznMlkPzZQjVTTQ==
X-Received: by with SMTP id i50mr31057955qti.89.1467759921498; Tue, 05 Jul 2016 16:05:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 5 Jul 2016 16:05:20 -0700 (PDT)
In-Reply-To: <>
References: <20160701153304.332d2c95@pc1> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Tue, 05 Jul 2016 19:05:20 -0400
X-Google-Sender-Auth: _xDWhmyKSiINpovkhQvHZiOB4j0
Message-ID: <>
To: Jon Callas <>
Content-Type: multipart/alternative; boundary="001a113efaaabc93ed0536eb7cba"
Archived-At: <>
Cc: IETF OpenPGP <>
Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jul 2016 23:05:24 -0000

On Mon, Jul 4, 2016 at 10:29 PM, Jon Callas <> wrote:

> To chime in with Peter and Andrey, this is something that can done in
> software.
> Not everything needs to be done in protocol.
> Whatever the details, one can (and perhaps should) use the same key
> material and dress it up in whatever uniform one wants, OpenPGP or S/MIME.
> While on the surface, it kinda seems like a good idea to unify the two in
> protocol, that's a different task than either group has. A new protocol
> would want to be a new protocol. Despite each protocol being used in much
> the same way (especially in email), there are a lot of things that would
> have to be re-hashed out.

The only reason to introduce a new protocol would be to introduce features
that aren't currently supported and would require a substantial
re-engineering of the legacy protocols.

Now I think I have actually found such a feature and might even write a
client to demonstrate it. But that would be in addition to supporting
S/MIME and OpenPGP etc. Because the lesson we learned on the Web was that
the gateways to legacy systems were what allowed the Web to beat systems
like HyperG etc. that most independent observers would have said were
'better' at the time.

I think that the idea of OpenPGP Key Server + Linked Timestamp (aka
Blockchain) is very powerful. I also think that I don't like ASN.1 or PGP
data encoding and a modern protocol should have a really good reason for
not using JSON or JSON plus extensions to support binary blobs without
Base64 armoring.

[OK I lied about saying I don't like ASN.1, I utterly despise it, there are
few things I loathe more]

> There's how you issue certificates (the whole CA/introducer issue(s)),
> whether certs contain one key or key sets, how they are transported (S/MIME
> puts them in the message, OpenPGP in directories etc.), and even the role
> of the internal layering. Note that OpenPGP is a binary (and UTF-8 is still
> binary) object protocol with a drizzling of MIME-encoding frosting over the
> top. That frosting is subject to its own interpretations. S/MIME in
> contrast *starts* with the email and MIME object and underneath there's
> CMS, usually almost as an afterthought. (Did you have a momentary "huh?" in
> your head when you read CMS? Many people do, and that's the point.) S/MIME
> starts at the top, OpenPGP starts at the bottom.
> And oh, there are also other things that have to be re-hashed like ASN.1
> all over again and the things it drags along like encoding rules. This is a
> good deal why perhaps its better to just push the other things up into
> software. The reason that there are the two standards is that they address
> different views of the world, technical as well as political.

​Two views of the world that are rather absolutist and thus wrong. Some
parts of the world are hierarchical, others are not. A trust infrastructure
needs to support both. But it isn't clear such infrastructure is best
implemented inside a client.

> At the end of the day, there are many things you *have* to push up into
> software. Consider the case where I am sending an email (which often
> happens, but may not even be the primary case in OpenPGP, merely the one
> that comes first to mind) to Alice, Bob, and Charlie. It's indeed
> irritating that Alice has an OpenPGP key and Bob an S/MIME certificate, and
> I am thus  going to have to code up two copies of the message. It is,
> however, straightforward. I know what to do. The subtlety comes from the
> fact that Charlie is being BCCed. It doesn't matter what happens with
> Charlie, whatever encoding we use (even plaintext) we have to send that
> message separately. You have to handle this at the software level no matter
> what. Even with a unified crypto standard, messaging isn't just crypto.
> Unless the unifying protocol is so compelling that people of all stripes
> can agree that we should drop the old ones and go to this, we merely have a
> reification of an XKCD cartoon -- we'll have *three* protocols that have to
> exercised at the proper software level in exactly the same way you'd have
> to hand it with two. Trying to simplify will almost certainly just make
> things more complex.

​If it is only a question of merging S/MIME and OpenPGP functionality, I
don't see it.

But Proxy Re-Encryption is a lot more powerful. Essentially it is the next
logical step in crypto. The trick in crypto is that we introduce a new key
for each function. Public key crypto is more powerful because encryption is
separate from decryption. With Proxy Re-Encryption we have Lora who is
managing a mailing list and she has a key that can add new members to the
list, and we have the mailing list encryption key and we have the per-user
decryption keys. Going from two key crypto to three key crypto is powerful