Subject: [Openpgp-dt] V5 test key pair

From: Daniel Huigens <[email-masked]>
Date: Thu, 03 Mar 2022 16:13:31 +0000

Hi all,

Here's a V5 test key pair, with the changes of the DT applied.

It has an Ed25519 primary key packet, with a direct-key signature with
key flags, features and preferences subpackets, including cipher suites,
and a Curve25519 subkey packet, with binding signature, and no User IDs
nor User ID self sigs.

The private key is unencrypted (I didn't have time to implement
HKDF-based key separation for private keys yet); it would probably be
nice to add an encrypted one in the future.

I'm able to parse them (after some hacky patches) also using go-crypto.
go-crypto's V5 implementation was originally written by someone else,
so this gives at least some comfort, though the new changes have been
made by me, so it's of course possible that I misinterpreted the spec
and implemented it wrong twice. Hopefully I didn't, but I'd still be
grateful if someone else wants to check them, though that's probably a
tall order before Monday. I'm relatively confident that they're correct,
though (knocks on wood :)) so I think they can be added to the document
(modulo the following point).

This key (with preferences in the direct-key signature) matches the
recommendations I proposed in [!134]. As I mentioned in the call after
Paul left, I personally still think it's a bit strange to add these
test keys to the document as-is without that text, so if folks want to
take a look at [!134] and see if they agree with it I'd be grateful.

There's still some other text in the spec that's conflicting with
[!134], though, e.g. about User ID specific preferences. So that would
have to be changed as well. I can make a MR for that as well, if people
agree, or we can do it afterwards, perhaps. Let me know what you think.

Best,
Daniel

[!134]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/134

---

From: Justus Winter <[email-masked]>
Date: Thu, 03 Mar 2022 17:49:13 +0100

> agree, or we can do it afterwards, perhaps. Let me know what you think.

I dumped the first two packets and did some manual parsing to fixup the
dump (because i haven't it implemented).  Looks plausible, haven't
checked subpackets or the maths:

Unknown or Unsupported Packet, new CTB, 2 header bytes + 55 bytes
    Tag: Public-Key Packet

   00000000  c6                                                 CTB
   00000001     37                                              length
   00000002        05                                           version
   00000003           62 20 d0 57                               creation time
   00000007                       16                            pk algorithm
   00000008                           00 00 00 2d               pk material octet count
   0000000c                                       09 2b 06 01   pk material
   00000010  04 01 da 47 0f 01 01 07  40 b5 50 fd 42 0b de 0a
   00000020  2a f2 da 98 c8 08 6a c7  5f 40 1b 96 07 b8 cc 80
   00000030  1e 30 8e 4f 25 29 54 ab  51

Unknown or Unsupported Packet, new CTB, 2 header bytes + 168 bytes
    Tag: Signature Packet

   00000000  c2                                                 CTB
   00000001     a8                                              length
   00000002        05                                           version
   00000003           1f                                        type
   00000004              16                                     pk algorithm
   00000005                 0a                                  hash algorithm
   00000006                    00 00  00 23                     hashed arena length
   00000003                                 05 02 62 20 d0 57   subpackets...
   00000010  03 15 08 0a 04 16 00 02  01 02 1b 03 02 1e 09 0d
   00000020  27 09 03 07 03 09 01 07  01 09 02 07 02
   0000002d                                          00 00 00   unhashed arena length
   00000030  23
   00000031     22 21 05 1b 44 29 d5  b6 fa 69 9b e4 c8 08 cf   subpackets...
   00000040  bb 5e 38 4f 37 16 22 61  f2 5d 7f 17 01 38 ce 2d
   00000050  30 0c df 4b
   00000054              01 ee                                  leftmost digest bytes
   00000056                    90 3c  95 63 5b 81 78 3d 57 3f   salt
   00000060  32 71 96 56 90 01
   00000066                    01 00  c8 23 b0 4d f8 12 d1 29   mpi(r)
   00000070  8c cd 3a 16 dc 3e f7 d8  17 8c f5 79 5f 2f f5 9a
   00000080  67 ac a0 6d c9 4d 95 7a
   00000088                           01 00 e0 80 68 44 90 48   mpi(s)
   00000090  06 ea 73 ac a5 cb e3 de  d9 d7 f1 f8 b7 fc d6 b0
   000000a0  d3 b0 c7 d1 a4 fc d4 0d  ed 06

Justus

---

From: Daniel Huigens <[email-masked]>
Date: Fri, 04 Mar 2022 16:11:57 +0000

Thanks!

Btw, I noticed one inconsistency in the document while implementing the
changes, re. the length of the subpacket counts. I've opened a MR to
fix that, here: [!150].

Also, if someone finds it easier to look at commits / code to try to see
and/or verify what it does rather than try to parse the key themselves,
I've pushed a branch of OpenPGP.js with the changes here: [#1505].

And finally, I remembered that I promised to send a link to an issue for
implementing the latest draft in general, that is here: [#1442].

Best,
Daniel

[!150]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/150
[#1505]: https://github.com/openpgpjs/openpgpjs/pull/1505
[#1442]: https://github.com/openpgpjs/openpgpjs/issues/1442

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 10 Mar 2022 05:09:08 -0500

> Here's a V5 test key pair, with the changes of the DT applied.

Thanks for creating this, Daniel!  and thanks for taking a look at it,
Justus.

I've proposed adding this certificate to the crypto-refresh draft as
part of a test vector cleanup merge request:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/152

> agree, or we can do it afterwards, perhaps. Let me know what you think.

I've reviewed !134 now, and my concern is not that it's doing too
little, but rather that it's trying to do too much at once. Its mixing
changes to preference disambiguation and hard MUST NOT check uid
selfsigs with placing preferences on the direct-key signature.

That might be making it harder to get consensus on the MR, even though i
thought we had reached consensus about v5 certs having preferences/etc
in direct key signature packets during our weekly live meetings.

I've opened [!153], based off of some of your text from !134, as a
possible next step forward -- preferences in v5 keys go on direct key
signatures, but i've softened the MUST NOT check uid self-sigs to a
SHOULD NOT, and used examples to identify some contexts where some
implementations might legitimately consider checking user ID self-sigs
(as well as examples of where it's probably inappropriate).

I agree that we need to move on to talk about preference disambiguation
in the places that remain, and would be happy to review related MRs.
I've opened [#103] about that.

feedback welcome.  merge requests even more welcome!

     --dkg

[!153] https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/153

[#103] https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/103