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

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Jul 4, 2016 at 10:29 PM, Jon Callas <[e-mail]> 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