[Top] [All Lists]

Re: [openpgp] Stripped Primary Secret Keys

2022-05-09 04:49:31
Hey Werner,

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[1] 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 Castle :P).

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