[openpgp] implicit PSK key capabilities

[Daniel Kahn Gillmor <[e-mail]>]

hey folks--

in the interim yesterday, we had quite a bit of discussion about whether
there should be explicit annotation of PSK capabilities (and if so, how
to do that), or whether the PSK should be declared implicitly capable of
a range of operations.

I'm not sure i have a strong preference, but the latter approach
(implicit capabilities) seemed easiest to write up.  I've taken a crack
at writing it down here:

  https://gitlab.com/twisstle/openpgp-persistent-symmetric-keys/-/merge_requests/7

the proposed added text is:

+## Reasonable Use
+
+A PSK is useful only to its keyholder, not to any peer of the keyholder.
+As such, its use is limited to interoperable operations
+between the keyholder's own OpenPGP implementations.
+
+While it has no explicit usage annotation (such as a Key Flags subpacket),
+the following uses are implicitly permissible for any PSK:
+
+- Encryption:
+  For example, it may be useful to re-encrypt
+  a session key from an existing OpenPGP Message
+  by prepending the message with another PKESK.
+  See "storing session keys," above.
+- Signing data:
+  For example, to mark a draft message
+  as authentic for the drafter,
+  an implementation may use the PSK to create
+  a signature of class 0x00 or 0x01.
+  This signature can be verified by the
+  keyholder's other implementations
+  that have access to the PSK.
+- Certification:
+  For example, to mark a verifiable local association
+  between a given certificate and a User ID,
+  an implementation may use the PSK to create
+  a certification (signature class 0x10-0x13).
+  Any certification created by a PSK
+  SHOULD be marked "non-exportable"
+  (see {{Section 5.2.3.19 of RFC9580}}).
+  The keyholder's other implementations that have
+  access to the PSK can then validate
+  the certificate for use in any context
+  where the User ID is relevant.
+

Feedback welcome,

         --dkg