Re: [openpgp] respecting key flags for decryption

[Jon Callas <[e-mail]>]

> On Nov 7, 2018, at 7:28 AM, Vincent Breitmoser <[e-mail]> wrote:
> 
> 
> Hey folks,
> 
> I'd like to get some opinions on a thing:
> 
> When a message is encrypted to a public key whose key flags indicate that it may
> not be used for encryption - should the receiving implementation still decrypt
> data using this key?
> 
> Personally I think the only cryptographically sane thing to do is to reject the
> data. There is no valid use case for this, and if it happens it's either a bug
> or an attack happening. I would also welcome a clarification in the spec that
> explicitly stated that a key MUST not be used for purposes that aren't indicated
> by its key flags.

I disagree. 

Before going further, let’s remember that if I set up my key so that I have a signing key and an encryption key (or even no encryption key), and Alice sent me something encrypted to my signing key, it’s *Alice* who has broken protocol, not me. Why punish me because someone else has a broken implementation?

Also let me say that if there’s an implementation that wants to do this, that’s fine. What I’m objecting to is that this would be in OpenPGP. OpenPGP oughta say that an implementation MUST NOT encrypt to a sign-only key, but it should leave it at that.

Additionally, I see nothing wrong with an implementation letting me know that this thing it decrypted was encrypted to my signing key. In fact, I’d prefer to be told that. I can think of circumstances in which this is impractical, but in general, I’d like to be told. 

If the software I run messes me up because someone else has a bug, I think I am justified in saying that my software has a resiliency problem. If the implementer came back and said that they do that because the OpenPGP standard says they MUST NOT, my reply would be that then the standard is broken with a resiliency problem. 

Imagine this conversation between Alice, who has a broken implementation, and me with a “correct one.”

Me:    Hey Alice, here’s a note about, blah blah blah, let me know what you think.
Alice: <Message I can’t decrypt>
Me:    Alice, I can’t decrypt what you sent me because you encrypted to my signing key. Could you re-encrypt to my encryption key?
Alice: <Message I can’t decrypt>
Me:    No, it happened again, could you try that again?
Alice: <Message I can’t decrypt>

Okay, so what do I do know? Here are some options:

* Change my key so that my signing-only key is dual-use.
* Give Alice my coordinates on Signal, Wire, etc.
* Send Alice an S/MIME cert for me and ask her to use that.

It’s suboptimal to set things up so that a single badly-behaving implementation can poison the community.

It would be completely reasonable in this situation to promote that signing-only keys are utterly broken because the XXX program doesn’t handle it correctly and that means that you’re screwed when someone picked the wrong software. It would be completely reasonable to ask the people not use OpenPGP in any form at all, because you’re screwed by this situation.

In short, the standard should not mandate fragile, brittle, or user-surly behavior. The standard should not forbid resiliency in the face of a bug.

We have one instance in the standard of mandated fragility, and that’s the Critical flag in some sub packets. In this case, the whole point of the feature is to make it brittle, but this is also why in general people will say not to use the Critical flag unless it’s really, really, really critical because you’re almost always just shooting yourself in the foot.


> 
> The reason why I bring this up is that it does come up in practice and at the
> moment, there is no consensus on how to handle such a case between OpenKeychain
> and GnuPG. See:
> https://github.com/open-keychain/open-keychain/issues/2413
> https://dev.gnupg.org/T4235

I’m with Werner on the gnupg side of this. In decrypting anyway, gnupg is doing something resilient. Moreover, gnupg is not merely a tool, it’s a reference implementation and as a reference implementation it needs to have meta-features for the purpose of debugging. 

	Jon