Subject: [Openpgp-dt] notes from 2021-10-01

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 01 Oct 2021 11:44:43 -0400

OpenPGP DT meeting 2021-10-01

# Present:
    
    Stephen
    Gniibe
    Daniel H
    Justus
    Paul
    dkg
    
# Meeting Slot

    Friday 1230 UTC doesn't work for Paul. Looks like either Monday 1230 UTC works for those on the call. First Monday meeting will be on Oct 11 1230 UTC. We will have a (maybe quick) chat on Friday Oct 8th at 1400 UTC.
    
# Curve448

- Looks like option-8 is preferred, option-8 being:
  https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/66
  but #66 depends on #64:
  https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/64/diffs

some agreeement on the call to prefer changes to 64
- Gniibe gave us a bit of history which helps, 

action: Paul will reach out to dkg later today and try fix 64/66 to where we can approve the resulting MR before tuesday 5th so Paul has a chance to push out a revised I-D

Proposal:
- header for columns says "MPI" explicitly
- table of MPI variants:
  - row "MPI" changed name to "integer"
  - all tables modified to use new names

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/71

Daniel H walked us through this change. 
Action: review and hit approve (if you do) by oct 5th
    
Justus considered adding a timestamp - Justus will create a MR for that.

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/72

Adding argon. Daniel H walked through this, esp the parameters proposed.
To check: is argon2id well supported in current codebases?
People on the call are ok to merge this even if the parameterisation may need to be discussed in the wider WG later. (May as well give 'em something concrete.)
Action: review and hit approve (if you do) by oct 5th

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/69

This is needed for #72 and should be uncontroversial.

Some discussion of SHOULD NOT vs MUST NOT for lower entropy strings or even of removing simple s2k and salted s2k entirely. Needs a bit of checking to see if any implementations have already done that.

Action: review and hit approve (if you do) by oct 5th.

# SED (without MDC)

Justus: We need to warn more strongly against this, including warnings against decrypting them.  There are providers that are sending messages with SED-wrapped attachments, and Thunderbird is getting pressure to decrypt them.

https://bugzilla.mozilla.org/show_bug.cgi?id=1729221

With e-fail, this is even worse.  we need to be stronger in our refusal.

Justus will supply text in an MR

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 01 Oct 2021 17:24:35 -0400

> OpenPGP DT meeting 2021-10-01

re: MR 64
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/64

>   - all tables modified to use new names

I just tried to make this change but it doesn't appear to be possible
for some fields in the tables. In particular, I can't change the "Public
Key Format" column to "Public Key MPIs" because for ECDH, ECDSA, and
EdDSA, they have non-MPI elements in them, the leading OID (which is not
MPI-encoded) for all of them, and then the trailing KDFParams field for
ECDH (also not MPI-encoded).

I could try to make the proposed change for every column that is *not*
the "Public Key Format" column, to see whether that works.  Would that
be ok?

Otherwise, i don't know how to address the outstanding concerns raised
on !64.  Maybe someone else could take a crack at fixing them?

Sorry to fail at this repeatedly,

      --dkg

---

From: Daniel Huigens <[email-masked]>
Date: Fri, 01 Oct 2021 22:58:49 +0000

Myeah, no, makes sense. I also didn't fully think that through,
apologies. Perhaps, as a sort of compromise also between the two
syntaxes / approaches, we could try to list both the encoding and the
contents in the table rows, such as:

ID | Algorithm | Public Key Format | Secret Key Format | Signature Format | PKESK Format
(...)
18 | ECDH  | OID, MPI(point bytes) [curve-specific point format, see ...], KDFParams | MPI(secret) | N/A | MPI(point), size octet, encoded key
19 | ECDSA | OID, MPI(point bytes in SEC1 format) | MPI(secret) | MPI(r), MPI(s) | N/A
22 | EdDSA | OID, MPI(point bytes in custom format) | MPI(secret bytes) | MPI(R bytes), MPI(S bytes) | N/A

Or, maybe `MPI(R bytes)` sounds too much like R is the length - we could
do `MPI(32 bytes of R)`, or even `MPI(first 32 bytes of the signature)`?
Anyway, some wordsmithing may be required, and the above may be a bit
overly verbose, but I think at least it should be reasonably clear?

If the above seems reasonable, I'm happy to take a stab at it.
Let me know what you think.

Best,
Daniel

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 04 Oct 2021 10:05:26 -0400

> overly verbose, but I think at least it should be reasonably clear?

This seems plausible to me.  I definitely prefer "MPI(32 bytes of X)"
over "MPI(X bytes)".

i'd hope that the format summaries, where possible, would use terms that
align with the table of curve formats or the table of scalar formats.
(that wouldn't be possible for stuff that has curve-specific choices,
like the ECDH pubkey format, thus the explicit call-out of
"curve-specific point format" looks good to me)

If you're up for trying to add a commit on top of the
tabular-pubkey-mpis branch that implements this, i'd be happy to review
it.

         --dkg

---

From: Daniel Huigens <[email-masked]>
Date: Mon, 04 Oct 2021 15:39:12 +0000

> tabular-pubkey-mpis branch that implements this, i'd be happy to review

Alrighty, will do, thanks!

> align with the table of curve formats or the table of scalar formats.

I assume you mean e.g. SEC1 vs compressed, and custom vs native -
the reason why I wrote the former is because, in my mind, "0x40" means
"native point follows", so "0x40 || point" is not the "native format",
"point" is, if that makes sense. Maybe there's a better name for it
than "custom", though section 13.2 also calls it "custom compressed" -
but I'm open to suggestions. Of course I do agree that we should be
consistent, but do you mind if I rename them in the table too?

Best,
Daniel

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 04 Oct 2021 14:15:30 -0400

> Alrighty, will do, thanks!

thanks, Daniel!

> consistent, but do you mind if I rename them in the table too?

as long as we have consistent and clear naming schemes, i'm not sold on
any particular naming scheme -- others might have different preferences.

if you want to change the tables to make them line up, that'd be
welcome.  But i feel like the term "custom" is a bit too fuzzy, since it
implies that it *doesn't* precisely describe what should go on the
wire.  i'd prefer precise shorthand in the tables where it's possible.

       --dkg

---

From: Daniel Huigens <[email-masked]>
Date: Mon, 04 Oct 2021 19:42:37 +0000

> wire.  i'd prefer precise shorthand in the tables where it's possible.

Yeah, that's a fair point. I'll think a bit about a better term, or if
anyone else has an idea it'd be welcome. Maybe I'll join the club and
propose a fancy acronym... Prefixed Native Octets? :)
(I'm not a huge fan myself, but barring anything better it could work..)

Best,
Daniel