# OpenPGP @ IETF 118   {#openpgp--ietf-118}

Note takers: Aron Wussler, Falko Strenzke

## Agenda bash   {#agenda-bash}

No bashing

## Crypto-refresh status   {#crypto-refresh-status}

dkg: Implementers, please have a look at the upgrade steps

## Rechartering, Milestones   {#rechartering-milestones}

dkg: We identified via a poll 4 topics (PQC, Superseded keys, Persistent
keys, WKD/HKP)  
Roman: Charter is being reviewed for initial review by Nov 30th, if
everything went smooth by the 3rd week of December it can be official

## Interoperability testing   {#interoperability-testing}

Justus: Implementations are tested against eachoter and standard
vectors. There is a filtered view for v6. All but gpg implemented good
parts of v6. If you have an implementation get in touch to add it to the
interop test suite.

## Post-Quantum Cryptography   {#post-quantum-cryptography}

Aron presents slides on PQC draft: summary ofchanges and request for
adoption for draft wussler. Algorithm choices haven't changed since last
few draft versions. NIST and Brainpool curves are included for
compliance.

Protocol bindings: v6 signatures required for PQC. Due to greater
urgency for encryption, v4 keys and v3 PKESK are allowed.

Main point today is teeing up the eventual call for adoption for
whatever draft(s) we have in hand at that point. Aron presents slide 10.
OpenPGP is slow with respect to standardisation of new schemes. Thus a
single step of migration with encryption and signatures is favored by
the authors. Signature separation is not an issue because algorithm ID
is part of the hashed data.

Questions:

Mike Ounsworth: concerning list of algorithms. All of S/MIME and TLS and
others should align on algorithm choices. There are no 521 bit classic
curves. Why the pairings PQ / T security levels?

Aron: the decision is still open. EC algos here are fallback. This
follows a certain government guideline. 256 bit is most widely supported
in hardware and software. But have no specific preference regarding
using 521 bit curves. We might also prefer fewer code points. All these
questions are still open. Measurements I have taken seem good.

Stephen: not all WGs will pick the same choices. For instance SSH will
do something different than others.

DKG: Further question how will you align parts of composites.

Mike: no pure ML-\* algorithms. In the future pure ML-\* algos may be
used.

Aron: OpenPGP has big burden of legacy algorithms. Keeping the EC beyond
certain point is not introducing any burden.

Stephen: We'll have to raise the question as to whether splitting the
draft is better or not.

Aron: NIST standards are expected within 6 months. OpenPGP WG is not
going to be faster. I see questions for all algorithms. Organisation of
code points for SLH-DSA and number of EC schemes in junction with ML-\*
is still an open question.

Stephen: who has read the PQC draft. 3 1/2 hands up. That needs to
change if we're to make progress.

Justus Winter reports about Hackathon: after some fiddling, GOpenPGP and
RNP worked together, did send e-mail over SMTP

Aron: all implementations are still using the submission versions of the
PQC algorithms.

DKG: requiring v6 keys creates a dependency impacting how fast this will
be widely supported. I think I understand all except supporting v1
SEIPD.

Aron: this is the only way to send an e-mail to one recipient who
supports v6 and one only v4

DKG: makes sense

Stephen: what does the WG want? Accept the draft as it is or split or
modify the draft first?

Mike Ounsworth: do adopt. it is/will be in charter. This work will be
done in one form or another.

Aron: finer points are still up for discussion.

Justus: I read the draft and would like it to be adopted.

Chris Inacio: should be adopted. Supporting Dilithium for itself is one
possible addition.

Aron: too early for that, overhead to add EC is small in both artifact
size and speed

Chris: for authentication the QC threat is not that strong

Stephen: two signatures on the protocol as alternative?

Aron: that would be and OR combination not an AND

Stephen: for backwards compatibility would have T signature and PQ/T

Aron: for two signatures on the protocol the semantics of the two
signatures may be different for the sender and the receiver

Stephen: When sending a signed e-mail would probably for long time send
also T signature with PQ sigature

Mike: this is a topic in PQUIP. Two separate signatures will not achieve
non-separability

Aron: achieving non-separability (through composite) is not too costly
for OpenPGP

A.J. Stein: Breaking up the draft would make sense if there are
implementers who would implement only a subset.

Aron: Size of the draft is fairly small for OpenPGP. Breaking it up
would increase the combined size of the drafts

Mike: split or not: KEMs and signature might be moving at different
pace.

Aron: if we wait 5 years to release Dilithium draft this might make us
miss the train

Mike: would e.g. Proton mail like to implement PQC encryption soon? (not
asking for commitments, just interest)

Aron: there is a marketing potential. Should not rush it to use
unstandardized algos. But I am not in the leadership of the company.

Daniel Huigens: we might use a private experimental algorithm internally
among our users. This is better than rushing this draft through the
standardization. But we should not make a draft here that supports
pre-final versions of the PQ algorithms.

DKG: sub code points for SLH-DSA. History of OpenPGP: 1 code point per
algorithm. Then came the curve parameters.

Aron: the question is whether this is relevant for security. different
than RSA that can go from 0 to infinite. SLH-DSA has reasonably secure
sub-code-points. reducing code points is a question for the WG
generally. WG should propose their prefences.

Stephen: with the current draft, is there further work required to use
it in e-mail?

Aron: at the e-mail summit I presented results. The user will not
recognize any difference. Artifats somewhat smaller. SLH-DSA is
different. But I would not recommend SLH-DSA for e-mail.

Stephen: and multiple signatures do not require any changes?

Aron: according to the c-r draft it is allowed and it has OR-semantics

Mike Ounsworth: have not heard of S/MIME client that does it. Happens in
code signing.

Julian Prat: is supported in JSON signature

Mike: windows code uses it

Jonathan Hammell: RFC 5752 specifies it for S/MIME

??: Clients in US federal gorvernment probably do not support it

Aron: in the draft the is a paragraph about e-mail transition. This part
could be split out into an informative draft.

Stephen: guidance for mail transition would be useful.

DKG: this is relevant for v6 transition

Stephen: will need more discussion on the list. Is something normative
needed regarding multiple signatures.

Aron: v6 transition will be more challenging than the PQC transition

Stephen: ask on list if WG prefers single PQC draft or splitting. Is
there additional guidance needed because of PQC

Aron: we have test vectors (still with minor errors). We will provide
test vectors in the draft.

Stephen: ask on list about whether to split the draft and if further
guidance needs to be included. Chairs will do that in the next weeks.

## Charter   {#charter}

Roman: I like the links to drafts / ML items but I don't know whether
they'll work in the tooling.  
Roman: What is the initial paragraph meaning?  
Daniel: The previous charter said we're working exclusively online, but
I noticed we're holding some face-to-face meeting so I re-adapted it  
Roman: I would remove that paragraph

(Issues were resolved subsequent to the meeting and before these minutes
were posted.)

## HKP   {#hkp}

Andrew: This is a revival of Daphne's draft, I've taken over as editor.
Done some neeeded uncontroversial changes to modernize the draft. Open
points:

*   Parameter for key versions
*   Padding
*   Shall it replace / augment WKD?
*   Authentication

Andrew: 3 documents (draft, +2 discussion documents)

Justus: I don't like the version selection. If clients can't ignore V6
keys, they should choke on them. Shall we then add a param for PQ as
well?

Andrew: It's reasonable to be nice to existing broken implementation

Aron: You can also define a supported feature list, or everyone who
supports v6 is also willing to accept garbage

dkg: There could be an option "I am willing to get information I won't
understand", and this would be an HKP v2, where V1 is serving the
classic info

Sthephen: This might take a while to be adopted (it's not 1st up in the
milestones we have now) - is that ok?

Andrew: I am not in a rush to get this out, has been around for 20y

## Any Other Business   {#any-other-business}

No other business