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

[Paul Wouters <[e-mail]>]

On Nov 25, 2022, at 08:56, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> 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.

That would be great for an appendix entry !

> 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.

Please do a PR. The example should really comply with the draft text and me as simple as possible.

Paul