I noticed that there is an issue related to this question in the
openpgp-wg issue tracker:
Personally I am of the opinion, that it should indeed be possible to
simply omit the secret key packet.
This might required changes to parsers though, so it's not easy to allow
this behavior retrospectively.
In general it would be nice though, if implementations would handle
omitted secret keys gracefully (according to the test suite, most
implementations do not unfortunately).
A transferable key would then only be a transferable secret key, if
there is at least one secret key (or secret subkey) packet present,
otherwise it would be a transferable public key.
Parsers would therefore need to parse the key completely before
determining if it is a TSK or TPK and should no longer make this
distinction dependent on the first packet (I'm looking at you, Bouncy
This would also solve the issue where a user is not allowed to "own" a
primary secret key, since as far as I understand, a dummy key means that
the secret key is present on some smart-card, which in this case might
be semantically wrong.
In any case I would like the standard to define a way to implement
stripped secret keys properly.
Am 09.05.22 um 08:22 schrieb Werner Koch:
On Sat, 7 May 2022 14:01, Paul Schaub said:
As far as I understand, GnuPG is using a (proprietary?) stubbing
mechanism to mark stripped secret keys.
Right. This uses the private S2K mode 101 followed by the string
when parsing the secret key, Bouncy Castle is complaining that the
secret key stream doesn't start with a secret key tag (since now the
first packet in the stream is the primary public key packet).
I consider this correct. You can't simply replace a secret key packet by
a public key packet.
openpgp mailing list