Re: [openpgp] respecting key flags for decryption

Jon Callas <> Wed, 07 November 2018 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3655B1294D7 for <>; Wed, 7 Nov 2018 14:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GS0uYGszi1Ct for <>; Wed, 7 Nov 2018 14:11:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51AE71286E3 for <>; Wed, 7 Nov 2018 14:11:34 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built May 31 2018)) id <> for; Wed, 07 Nov 2018 22:11:33 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=04042017; t=1541628693; bh=LpFOzOGjD7tEwSmsO2+9HKikOxrASJJ+JQoMgUybjHE=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=ggZu7R75tZFsEDM21E4zp5IABP6XKlJVdxJjARo1wgiNrHMwFwYYJkgwNhu7hNmpE nrhjQjYAfwy8GRYZqfJtCT8PmZM6fDZ7jdpiCi1ybyq7Lc+SYCgj5vPsGYxAnYwQ7V RfB41V8PXDLs/tftIhmZ0YQgOOVdV/dSwQeWFTXF7fxOxIqmXxfnFzCr3tB/gfUuZE qF95gAcz1Fm5NAYiANt+1fy2AezJ4wSmfEc/aPNIKLcRpNL2yrGVg0BOD2Hdw17l0e Avc5wc2x5rDi80NH/UAbvzDofgny18MOLFarzpmebkMAvkm4436VmIeBU657AustRF kXoLOVdnG4QGw==
Received: from ([]) by (Oracle Communications Messaging Server 64bit (built May 31 2018)) with ESMTPSA id <>; Wed, 07 Nov 2018 22:11:32 +0000 (GMT)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811070196
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-07_18:,, signatures=0
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Jon Callas <>
In-reply-to: <>
Date: Wed, 07 Nov 2018 14:11:29 -0800
Cc: Jon Callas <>,
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <>
To: Vincent Breitmoser <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [openpgp] respecting key flags for decryption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Nov 2018 22:11:36 -0000

> On Nov 7, 2018, at 7:28 AM, Vincent Breitmoser <>; 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:

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.