Subject: [Openpgp-dt] notes from 20210917

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Sep 2021 17:02:02 +0100

OpenPGP Design Team
2021-09-17

attending

dkg
justus
paul
daniel huigens
stephen

We'll ask for a meeting at IETF 112 (may cancel later)

in the next two weeks, try to get a draft out that includes 448

Meanwhile back to...
# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/61

"still live"

wo options: 5 and 8:

## Option 5: Simple Octet Strings

Simple Octet Strings (SOS) are a proposal by Gniibe to simplify the
handling of leading zeros going forward.

SOS(data) is defined as:
- If data[0] == 0, then: (two bytes containing length(data) * 8) || data
- Otherwise: MPI(data)

- EdDSA key: OID, SOS(public key); SOS(private key seed)
- EdDSA signature: SOS(r), SOS(s)
- ECDH key: OID, SOS(public key), KDF; SOS(private key)
- ECDH message: SOS(public ephemeral key), one-octet length || symmetric 
key

I believe this is what GnuPG 2.3-beta implemented; correct me if I'm wrong.

## Option 8:

Prefix octet (can be decided later): 0x4F or 0x40?

- EdDSA key: OID, MPI(prefix || public key); MPI(prefix || private key)
- EdDSA signature: MPI(prefix || 448sig), MPI(0) // trailing 0 MPI to 
match OpenPGP ECC expectations
- ECDH key: OID, MPI(prefix || public key), KDF; MPI(prefix || private key)
- ECDH message: MPI(prefix || public ephemeral key), one-octet length || 
symmetric key

On the  call:
     - Q: can you not live with any of these? A: nobody can't live with 
'em but this group prefer 8 over 5

dkg: will try to restructure !61 along the lines of his recent e-mail to 
the list, and will also break out PKESK and Signature text (not just 
pubkey and private key) into sections/subsections for ease of reference.

consider adding speculative sections of the interop test suite that 
include I-D details that haven't made it into a draft

# dealing with encrypted secret keys when keystore may have been 
tampered with

Attack described at IETF-110

can we include pubkey algorithm + material in the additional data to 
limit these attacks?
can we recommend checks that pubkey matches?  (expensive for elgamal)

We'd (those on the call) like to specify a way to prevent this attack 
and give implementation guidance (e.g. additional checking vs. public 
key) for those who can't adopt our preferred mitigation.