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

ianG <> Sun, 14 August 2016 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5950412B01D for <>; Sun, 14 Aug 2016 07:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bqp-DSXpnueK for <>; Sun, 14 Aug 2016 07:37:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8BD412B016 for <>; Sun, 14 Aug 2016 07:37:47 -0700 (PDT)
Received: from tormenta.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EE7CA6D748; Sun, 14 Aug 2016 10:37:45 -0400 (EDT)
References: <20160701153304.332d2c95@pc1> <> <> <> <> <> <> <>
From: ianG <>
Message-ID: <>
Date: Sun, 14 Aug 2016 10:37:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Sun, 14 Aug 2016 14:37:49 -0000

On 6/07/2016 18:12 pm, Phillip Hallam-Baker wrote:
> On Wed, Jul 6, 2016 at 10:59 AM, Derek Atkins <
> <>> wrote:
>     Phillip Hallam-Baker <
>     <>> writes:
>     >     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.
>     OpenPGP can support hierarchical certificate deployments just fine (my
>     company is building one) as well as the Web of Trust model.  X.509
>     cannot support a Web of Trust deployment, period.
>     So there is a clear winner here.
> ​
> You can in fact make X.509 do Web of trust. You simply give each user
> their own CA root and cross certify.
> I was doing that for quite a while till I realized that the legacy stuff
> was hurting rather than helping. Yes you can get the protocols to do
> more than the apps let them. But you don't have the advantage of legacy
> platform support or legacy platform ignoring your stuff in a predictable
> way.

Right - that word legacy.  My experiences are that you can get both of 
the tech stacks to handle the requirements with enough nailing and pain. 
  But at some point the tech stack starts to interfere too dramatically, 
and you're better off starting again.

One issue to bear in mind is that we are talking about a rather narrow 
and dated concept - email.  In the pre-web world, all comms was 
basically email.  Most comms these days is not email.  And, what we knew 
about what was interesting in the late 1980s early 1990s is no longer 
the text book.  Other methods/views/requirements are much more interesting.

Which is to say, we could narrow the scope so that we could get these 
tools to finally slay the dual standard dragon, but we'd still be 
slaying a beast that is no longer big and scary.

iang, chiming in yonks late.