Subject: [Openpgp-dt] What's left before WGLC?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 02 Nov 2021 19:42:13 -0400

Hi OpenPGP DT folks--

I wanted to open up discussion about what's left before we aim for a
working group last call on the crypto refresh draft.

We've been using the gitlab issue tracker and merge requests (MRs) for
this process thus far with reasonable success, so I think it might be
good to try to get all these points in the same spot: if we can make it
so that each outstanding concern has at least an issue (preferably an
MR) associated with it, then it should be easier to see our way to the
end of the process on the tracker.

I know we're currently engaged in some discussion around choices of
algorithm MTI decisions (MR !48).

What else do we have left besides that?  I'm reviewing the issue
tracker, the outstanding MRs, and the commits in the "step-by-step"
branch that haven't yet been applied to main to see what we have left.

In this message, I'm skipping over items that look like wordsmithing or
"document massage" to me, but you might feel differently about them.
Please highlight and call out anything you think i've missed!

Remember that some of these might be resolved by deliberate inaction
(e.g. closing an associated MR once it's clear that there is no
consensus in favor of the proposed change).

Here are some substantive MRs that need DT discussion:

 - Should we salt v5 signatures? (MR !91)

 - Can a certificate lack a (self-signed?) user ID? (MR !49)

 - How should a v5 signature be formed? (MRs !85 and !86)

Some substantive issues (which do not yet have MRs):

 - Updating key size cutoffs (#54)

 - Deprecating RSA sign+encrypt in favor of RSA sign-only and RSA
   encrypt-only (#53)

 - Using RSA-PSS for RSA v5 signatures and RSA-OAEP for RSA PKESK
   pointing at v5 keys (#22)

 - Usability of SHA256 fingerprints (#44)

From the step-by-step branch, i see at least the following changes that
i'm certain are in-charter if we decide we want them to be in the
updated RFC:

 - Preferred AEAD modes subpacket (alternative: we could drop mode
   flexibility for AEAD v1 by mandating only EAX or OCB)

 - Brainpool curves

The following pieces of the step-by-step branch might not be explicitly
part of the crypto refresh, but they might be useful in other .  Do any
of them have enough widespread support within the DT that we want to
consider them before we go into WGLC? (remember that if we get a new RFC
out, the WG can re-charter to do any of this kind of work in subsequent
drafts; codepoints will remain reserved in any case).

 - Key Block subpacket

 - Attested Certifications subpacket

 - Official notation registry

 - 'm' MIME format flag

 - Key Usage Flag: ADSK (additional decryption subkey)

 - Key Usage Flag: timestamping

 - User ID Attribute subpacket

What do y'all think?  Is there triage we can do?  What do we need to do
to get to WGLC?

   --dkg

---

From: Daniel Huigens <[email-masked]>
Date: Wed, 03 Nov 2021 17:39:48 +0000

Hi dkg,

Thanks for making this list.

My overall opinion is that many of the improvements that have been made
in the crypto-refresh so far, or are in progress (adding more modern
algorithms, deprecating old stuff, etc) are important enough
(and long-overdue) to the point where I think it's valuable to emit an
RFC sooner rather than later, and then re-charter if needed.

So I agree we should address the existing MRs and issues, but then
personally I would err on the side of not adding anything more. With
the exception of...

>    flexibility for AEAD v1 by mandating only EAX or OCB)

I forgot that we hadn't done this one yet (and consider it part of the
AEAD changes), so I'd be in favor of still adding that (and also
mandating EAX or OCB). There may be legitimate performance reasons for
an implementation to prefer one or the other. We implement it in
OpenPGP.js and gopenpgp and emit EAX as the preferred AEAD algorithm by
default when enabling AEAD (EAX is faster for us, e.g. due to platform
support for AES-CTR on the web), which will be significant if we decide
to mandate OCB (which I think would be reasonable since it's a CFRG
recommendation while EAX is not).

It may also be valuable to be able to signal support of one of the
private/experimental algorithms (we implemented GCM as 100, as it's the
fastest for us, though we only include it if the user/app explicitly
chooses "experimentalGCM" as their preferred AEAD algorithm).

Best,
Daniel