Re: [openpgp] A more modest proposal for domain separation

[Wiktor Kwapisiewicz <[e-mail]>]

Hi Daniel,

On 24.11.2022 16:54, Daniel Huigens wrote:
> 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.

I agree that having separation here is a good thing and I've seen that 
in other contexts, e.g. signing commits, signing tags. Actually I think 
I remember an issue where signed git pushes "git push --signed" could be 
abused to sign arbitrary data and as such have been modified to contain 
seeds etc [0].

For me it seems the problem is not having something like Extended Key 
Usage [1] for subkeys so that their usage can be further restricted 
(e.g. "signing, but only commits for openpgp.js", "signing but only 
e-mails").

Why does the subkey need to be restricted and not the signature that is 
produced by the subkey? Since usually the signing API (e.g. hardware 
token) only sees a digest that is signed and cannot "check" what is 
being signed.

This would avoid the "Name (Code Signing)" certificates since one could 
use their usual certificate and just designate one of their subkeys for 
code signing and even store that on a separate token.

I'm aware that your primary use case - e-mail - doesn't overlap mine 
completely but I'm convinced that it is possible to find a good enough 
solution for both cases :)

Kind regards,
Wiktor

[0]: https://people.kernel.org/monsieuricon/signed-git-pushes

[1]: https://ldapwiki.com/wiki/ExtendedKeyUsage