Message-ID: <817f5197-093a-4a99-9b7a-8672f548a304@posteo.de>
Date: Wed, 30 Sep 2026 14:37:58 +0000
MIME-Version: 1.0
To: openpgp@ietf.org
References: <87qzih40no.fsf@fifthhorseman.net>
 <B7B1C94C-DDB3-43AD-82AA-5F6697C04C47@andrewg.com>
 <87jyo93usz.fsf@fifthhorseman.net>
 <2d33a3fa-728c-42e9-8a59-9689d26ec4b0@andrewg.com>
 <axuymXzPrSvxBcsfsU5XxAzkQyqKhh6NPEmoHzrJq0aB_ZoBsVFqbOjAfVltNi3ouVyciWJ5tLOZ4AHSlV_xh_zAnJpcOCDfPjx0XiekuAc=@protonmail.com>
Content-Language: en-US
From: =?UTF-8?Q?Heiko_Sch=C3=A4fer?= <heiko.schaefer@posteo.de>
In-Reply-To: 
 <axuymXzPrSvxBcsfsU5XxAzkQyqKhh6NPEmoHzrJq0aB_ZoBsVFqbOjAfVltNi3ouVyciWJ5tLOZ4AHSlV_xh_zAnJpcOCDfPjx0XiekuAc=@protonmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID-Hash: HXY5W7X2OZFDSX5JJF45A7NED5BPERXF
Precedence: list
Subject: [openpgp] Re: implicit PSK key capabilities
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/2hXsB21QxdMAbs1-RxVgFsVB2_s>

Hello Daniel, all,

> 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.

I'm very happy with this approach (and the specific language in the MR).

As an implementer, I'm happy that we're keeping the TSK structure 
limited to a bare PSK.
Also, clarifying that all key usages are implicitly allowed (at the 
discretion of the keyholder's software) seems good to me.

Thanks,
:) Heiko