On Mon, Jul 4, 2016 at 10:29 PM, Jon Callas <joncallas(_at_)icloud(_dot_)com>
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp