[openpgp] Re: implicit PSK key capabilities
Daniel Huigens <d.huigens@protonmail.com> Mon, 28 September 2026 14:29 UTC
Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id A752331 for <openpgp@ietf.org>; Mon, 28 Sep 2026 14:29:16 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=mU8Ep0qR; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx.ietf.org: domain of d.huigens@protonmail.com designates 109.224.244.17 as permitted sender) smtp.mailfrom=d.huigens@protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1790605748; x=1790864948; bh=ShWFqQ1ME0rSOjJseA5KE3U+IPPThFB1XedvvZ+eqgY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=mU8Ep0qRJYWl1ymkgjXV85j+YcxFm3vIBQy/5eqN/iOtdHUaPW16OtPYeO+aJIihv 2KjBc8Lih5UD3ubDHVOD5USuJUzVQ38Qy3MoAgA3vNjlQUqfwsQfGCQLsBy4z/xwW9 uKyT4VDklx1C/10tzorllgEVqvG4s7+1sAo4J6PfMfb+l9ACjncKyhH2de3dKZhBkP RY1q9Q09euEyrH3fj+RrEjgL/spY2YrC6J9MW6gD3A1jVR6c7bzFEcPBmbj6GNDGWd fOwTgwVhYQkRYq4y1eLTNphcgloT82ilcN1hsbuWNUGC7CGsb6itriYdLdS7zzzU83 wmM0EXWE2HJeg==
Date: Mon, 28 Sep 2026 14:28:56 +0000
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
From: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <axuymXzPrSvxBcsfsU5XxAzkQyqKhh6NPEmoHzrJq0aB_ZoBsVFqbOjAfVltNi3ouVyciWJ5tLOZ4AHSlV_xh_zAnJpcOCDfPjx0XiekuAc=@protonmail.com>
In-Reply-To: <2d33a3fa-728c-42e9-8a59-9689d26ec4b0@andrewg.com>
References: <87qzih40no.fsf@fifthhorseman.net> <B7B1C94C-DDB3-43AD-82AA-5F6697C04C47@andrewg.com> <87jyo93usz.fsf@fifthhorseman.net> <2d33a3fa-728c-42e9-8a59-9689d26ec4b0@andrewg.com>
Feedback-ID: 2934448:user:proton
X-Pm-Message-ID: 68dd435479f2ef6a397cd30d2aebdd18749ff21b
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Bar: -
Message-ID-Hash: XSRXNX7WC5MP7EAXQEVDYUHNZL5GXQ45
X-Message-ID-Hash: XSRXNX7WC5MP7EAXQEVDYUHNZL5GXQ45
X-MailFrom: d.huigens@protonmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-openpgp.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, openpgp@ietf.org
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [openpgp] Re: implicit PSK key capabilities
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/ijCj4RuuPDoIPVM0jsJN5wDjVUU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>
Hi all,
Thanks dkg for the concrete MR, and thanks all for the discussion!
I agree it should be fine to permit PSKs to be used for all usages.
The PSK draft itself has domain separation between encryption and signing,
and the OpenPGP spec has domain separation between different types of signatures.
If we add a new type of signature that should already be covered,
and if we add an entirely new type of key usage that could be covered
by PSK's domain separation (but may need to be considered separately).
So, I've created an alternate MR to address both this question and the
one about revocation & expiry, as follows: [!8]
> ## Key Metadata
>
> Because a Persistent Symmetric Key cannot include a direct-key
> signature, there is no place to include a Key Flags subpacket
> (as defined in {{Section 5.2.3.29 of RFC9580}}) to indicate the
> permissible key usages.
> Instead, Persistent Symmetric Keys are implicitly allowed to be used
> for all usages (certification, signing, encrypting communications and
> storage, and authentication).
> If a keyholder or application developer wishes to restrict the key
> usages, they may add metadata external to the key indicating the
> intended usages, instead (and process it before passing the key to
> the OpenPGP implementation).
>
> Additionally, Persistent Symmetric Keys cannot expire, nor be revoked.
> If a keyholder or application developer no longer wishes to use a
> given key, they may either add metadata external to the key indicating
> that it should no longer be used, or destroy the key material (after
> re-encrypting and re-authenticating any data that is still relevant
> with a new key) if that is practical.
Let me know (here or in the MR) if that seems reasonable.
Best,
Daniel
[!8]: https://gitlab.com/twisstle/openpgp-persistent-symmetric-keys/-/merge_requests/8
- [openpgp] implicit PSK key capabilities Daniel Kahn Gillmor
- [openpgp] Re: implicit PSK key capabilities Andrew Gallagher
- [openpgp] Re: implicit PSK key capabilities Daniel Kahn Gillmor
- [openpgp] Re: implicit PSK key capabilities Andrew Gallagher
- [openpgp] Re: implicit PSK key capabilities Daniel Huigens
- [openpgp] Re: implicit PSK key capabilities Heiko Schäfer
- [openpgp] Re: implicit PSK key capabilities Daniel Huigens