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

From: Stephen Paul Weber <[email-masked]>
Date: Thu, 4 Aug 2016 09:35:04 -0500

>I think it was a big mistake to create two competing standards in the
>first place, but that was back in the 90s. So we may ask if we want to
>live forever with this situation or if it can be fixed.

If we can convince any CAs to start issuing OpenPGP signatures, then OpenPGP 
already has the features to support this mode of operation.  So it's really 
just about formats / software support, etc.

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

---

From: ianG <[email-masked]>
Date: Sun, 14 Aug 2016 10:37:44 -0400

On 6/07/2016 18:12 pm, Phillip Hallam-Baker wrote:
>
>
> On Wed, Jul 6, 2016 at 10:59 AM, Derek Atkins <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Phillip Hallam-Baker <[email-masked]
>     <mailto:[email-masked]>> 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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Aug 2016 16:29:47 -0400

On Sun, Aug 14, 2016 at 10:37 AM, ianG <[email-masked]> wrote:

>
> 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.
>
> tools to finally slay the dual standard dragon, but we'd still be slaying a
> beast that is no longer big and scary.
>

​My thoughts pretty much.​

I see three possible paths towards convergence and I am trying for all
three.

1) Converge S/MIME and OpenPGP standards to the point that they are
functionally interoperable. So just like the fact that 120V and 240V are
still in use, pretty much every laptop you buy will work on either without
issue. The supply voltage is no longer an issue for most equipment.

2) As in (1) above but the systems merge to the point that one or the other
'wins'.

3) Propose a completely new infrastructure that might supersede both
because it offers a major functional advance.

​I don't see much point in a third standard that does the same as OpenPGP
and S/MIME. But where there is opportunity is to offer wider functionality.

* If I have someone's public key, I should be able to contact them securely
by mail, chat, messaging, voice or video. ​

​* Integrating proxy re-encryption into the system so that it is possible
to have end to end secure confidential mailing lists, controlled document
distribution and support for individually keyed devices.

Right now I am looking at how to make use of proxy re-encryption as a
'clean slate' proposal. Once I get that working we can look at the system
and decide whether it makes sense to back-engineer it into legacy systems
or not. ​