Re: [Openpgp-dt] v5 keys and hardware tokens (issue #63)

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

On Wed 2022-03-16 21:18:14 +0900, NIIBE Yutaka wrote:
> If we can assume some constants (like ECDH KDF parameters), OpenPGP
> fingerprint can be derived with raw public key material plus timestamp.
> When I tested in the past (in 2019) for v5 key, I did that.

Thanks, this makes sense.  I'm inclined to try to write up a bit of
text, as guidance for implementers dealing with hardware constrained
such that it can't transport v5 fingerprints.

I was thinking of making it a subsection of the "Implementation Nits"
section.

There are a few different ways forward, probably the simplest would be
to document something like my earlier (b) proposal:

      assert that the secret key material can be stored in these cards and
      used with them, but v5 fingerprints will not be stored.  fingerprint
      fields for v5 keys will be set to a fixed magic value (maybe 20
      octets of 0x05 ?).  The cards can only be used if the user can
      extract the public key material from the card, formulate a v5 pubkey
      from it, and compute the fingerprint directly via local computation,
      not on the card.

and suggest how to guess at the likely KDF parameters if the key in
question is in fact ECDH.

(speaking of ECDH KDF parameters, it would be great to test whether
those extension points are actually functional -- i've opened
https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/80
in case anyone wants to take a crack at testing them against the
deployed base)

Any preference on how this gets done?  Any pointers on how an
implementation should guess at the KDF parameters?

(followup on #63 would also be useful here)

               --dkg