Re: [openpgp] reviewing sample v5 certificate: can't validate internal signatures

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

Much obliged, Daniel!

I think your sequence is the right one.  I used it to figure out where
the bugs were in the implementation i've been tinkering with (it wasn't
just the mis-represented pubkey; i also had a problem where the
implementation was clearing feature flags it didn't know about (and it
didn't know about the SEIPDv2 feature flag yet).

On Tue 2022-11-22 19:56:22 +0000, Daniel Huigens wrote:
> The values we hash are:
>
> a)
> 903c95635b81783d573f3271965690019a00000037056220d057160000002d092b06010401da470f01010740b550fd420bde0a2af2da98c8086ac75f401b9607b8cc801e308e4f252954ab51051f160a0000002305026220d0570315080a0416000201021b03021e090d2709030703090107010902070205ff000000000000002b

Here is a broken-out representation of this stream, in a format inspired
by the nice rendering that Sequoia produces with "sq packet dump --hex".
The first column is the byte index (in hex), and each byte is
represented in hex.  Each row is 8 octets wide.

```
0000  90 3c 95 63 5b 81 78 3d  salt
0008  57 3f 32 71 96 56 90 01
           [pubkey begins]
0010  9a                       v5 pubkey
0011     00 00 00 37           pubkey length
0015                 05        pubkey version
0016                    62 20
0018  d0 57                    Creation Time
001a        16                 key algo: EdDSA
001b           00 00 00 2d     key length
001f                       09  OID length
0020  2b 06 01 04 01 da 47 0f  OID (Ed25519)
0028  01
0029     01 07                 MPI length
002b           40              prefix octet
002c              b5 50 fd 42  x coordinate
0030  0b de 0a 2a f2 da 98 c8
0038  08 6a c7 5f 40 1b 96 07
0040  b8 cc 80 1e 30 8e 4f 25
0048  29 54 ab 51
           [trailer begins]
004c              05           sig version
004d                 1f        sig type: direct key signature
004e                    16     sig algo: EdDSA
004f                       0a  hash algo: SHA2-512
0050  00 00 00 23              hashed subpackets length
0054              05           sbpkt length
0055                 02        sbpkt type: Signature Creation Time
0056                    62 20  Signature Creation Time
0058  d0 57                       (2022-03-03T14:27:35Z)
005a        03                 sbpkt length
005b           15              sbpkt type: Pref. Hash Algorithms
005c              08 0a        Hash Algos: [SHA2-256 SHA2-512]
005e                    04     sbpkt length
005f                       16  sbpkt type: Pref. Compression
0060  00 02 01                 Compress Algos: [none ZLIB ZIP]
0063           02              sbpkt length
0064              1b           sbpkt type: Key Flags
0065                 03        Key Flags: {certify, sign}
0066                    02     sbpkt length
0067                       1e  sbpkt type: Features
0068  09                       Features: {SEIPDv1, SEIPDv2}
0069     0d                    sbpkt length
006a        27                 sbpkt type: Pref. AEAD Ciphersuites
006b           09 03           [AES256-GCM
006d                 07 03      AES128-GCM
006f                       09   AES256-EAX
0070  01
0071     07 01                  AES128-EAX
0073           09 02            AES256-OCB
0075                 07 02      AES128-OCB]
0077                       05  sig version
0078  ff                       sentinel octet
0079     00 00 00 00 00 00 00  trailer length
0080  2b                                              
0081
```

I wonder whether it makes sense to include something like this as an
example in the draft itself, to make it easy for implementers to check
their work with a concrete example.

We could include it with a title like "octet sequence hashed for
the direct key signature in sample certificate".  Maybe in an appendix?
Keeping such an "artwork" to 8 octets per row makes it possible to fit
it into RFC's text column-width constraints and still have a fairly
intelligble description column.

> b)
> 5222aad2131c7b739aba14d74930a6559a00000037056220d057160000002d092b06010401da470f01010740b550fd420bde0a2af2da98c8086ac75f401b9607b8cc801e308e4f252954ab519a0000003c056220d05712000000320a2b060104019755010501010740ec2ae8314d049db9cfc67f58a440f760469700509df267198045ee13c1325d7f03010807051816080000000905026220d057021b0c05ff0000000000000011

I can do the same breakdown as above for this sequence if people think
it would be useful for the documentation.

> P.S. It's a bit weird that we used SHA512 for one and SHA256 for the
> other, indeed. It seems there's some missing code for the subkey
> binding signature to use the preferred hash algorithm, which I set to
> SHA512 when generating that key, so it used the default hash for the
> curve, SHA256. We'll have to fix that too.

It's also a little bit weird that the draft's sample cert is advertising
a AEAD ciphersuite preference for GCM and EAX over OCB, given the
draft's clear preference for OCB, and that it's using SHA2-512 to sign a
certificate that advertises a preference for SHA2-256 over SHA2-512.
And it's odd that there is no symmetric cipher preference list, given
that the Features subpacket advertises support for SEIPDv1.

I'd propose the sample cert should list the following simple and fairly
narrow preferences to exercise some of the new directions that the
update is heading toward:

 - hashes: sha2-512 sha3-512 sha2-256 sha3-256
 - symmetric ciphers: aes256 aes128
 - compression: none
 - AEAD: aes256-OCB aes128-OCB

What do y'all think?  I don't think this is worth engaging in a conflict
over, as it's just an example; if folks want to keep the current values,
i'm happy to keep it as is.

    --dkg