On Nov 7, 2018, at 7:28 AM, Vincent Breitmoser <look@my.amazin.horse> 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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp