[openpgp] A more modest proposal for domain separation

[Daniel Huigens <[e-mail]>]

Hi folks,

We discussed domain separation / context parameters at IETF 115. There,
we were talking about adding a registry for applications, and filling
in the initial values for such a registry, etc, and it sounded like the
conclusion was that that's a lot of work and to table it for now.

I want to try to formulate a simpler approach, with perhaps a more
modest (initial) goal, compared to the one we initially approached this
from. Rather than (immediately) considering context binding in the case
of email, or other existing applications, I would like to achieve that
new applications or protocols that want to use OpenPGP in a way that's
entirely internal to that application or protocol, but still want to
use the existing key infrastructure (i.e. use existing keys from WKD or
keys.openpgp.org or so) can be immune to context confusion; i.e. they
can be reasonably sure that a given message or signature was created by
that application, and not by other existing uses of OpenPG (e.g. email).

This is particularly important if the application wants to subsequently
process the message in some way which is potentially security-sensitive.
For example, imagine a backup system that encrypts backed-up files with
your existing keyring, and stores the backup on an external (untrusted)
server. It would be bad if that server could take an email you sent or
received and insert it into a backup, if it would later get restored and
written to disk, e.g. in a location where it would/could be executed.

(Of course the devil is in the details and that attack might not work
exactly as described, depending on the implementation, but I think it's
better to categorically exclude the possibility of this happening.)

---

With signatures, it's possible to achieve this today, as has been noted,
by creating a notation signature subpacket, and checking that that's
there when verifying the signature. However, this has an overhead, which
could be avoided by using a dedicated parameter that's hashed into the
signature but not stored there.

For messages, it's not possible at all, today. (For public-key encrypted
messages, this isn't as relevant since anyone could've created them,
anyway, but for symmetrically encrypted & integrity protected messages,
it's more relevant.)

I think a registry is not actually really required for this, if we state
that the application identifier should be a domain that the application
controls - or, for protocols, it could be rfcXXXX.ietf.org, or so.
Or, whatever the protocol wants, really, as long as it's confident that
other applications or protocols won't accidentally use the same value.

And, to simplify things, we can say that for existing applications, the
application string is initially assumed to be empty, unless there is
some specification or application-side migration that starts making use
of it, and signals as much with an email header or some such, but for
the OpenPGP spec itself it should be out of scope.

---

The above could be achieved by adding an "application" parameter
(prefixed by its length, perhaps) into the hash for signatures, and
into the additional data for messages.

Then, if we want to be future-proof, we could also add an application-
specific "context" parameter, after that; or we could have a single
parameter with some guidance on how to format it; e.g. something like
example.com:application-specific-context.

Let me know if this sounds reasonable, and if so, which variant you
prefer, then I can write up some text for this. Or, if you think this
is still too much work for the WGLC, that's fair enough as well, though
personally I think it would be nice to have this for v6 signatures,
already (if we end up bumping the version numbers, indeed).

Thanks!

Best,
Daniel