Skip to main content

Minutes IETF113: openpgp

Meeting Minutes Open Specification for Pretty Good Privacy (openpgp) WG
Date and time 2022-03-21 09:00
Title Minutes IETF113: openpgp
State Active
Other versions markdown
Last updated 2022-03-28


OpenPGP at IETF 113

Thanks to Aron and Florence for taking notes.

Agenda Bash

Nothing to change

Design Team

Chartered Work

Current draft - draft-ietf-openpgp-crypto-refresh-05

Justus Winter
Who has read the draft? - Raise hand: 8, Do not raise hand: 20

* AEAD - decided to go with SEIPDv2 not to go with v2 directly. Adds a salt to reuse key material across responses. Chunking in 64k to 4M. GnuPG and Sequoia have implemented this in an interoperable way. Werner states GnuPG is not an official release.
* v5 Keys, need to know how many octet has a key to compute the fingerprint. OpenPGP.js has an implementation, Gopenpgp is interoperable.
* Argon2 as KDF. GnuPG and Sequoia have implementations
* Signature packet: add prefix salt, change the issuer KeyID to the fingerprint. OpenPGP.js has an implementation.
* Padding packet: Can appear anywhere, random (to avoid compression), free from form.
* Other general improvements: MPI to store data, Legacy format is from 1998, Intended recipients for signatures, Keys w/o userID (discussed later)
* Algorithms: Must: EdDSA (Ed25519), and ECDH (Curve25519), mandatory AES-128 OCB, SHA256
* KeyIDs: v5 fingerprints are 32 octets, and keyIDs 8 octets - consensus: don't display fingerprint to users

* Werner Koch (WK) dropped out of DT in summer, stating the critical questions were already done. Still, since then there are large changes from then. AEAD started being deployed 4y ago, and is now being reworked already. The old AEAD packets were deprecated and new packets were added. Also doesn't think that adding a new KDF is a good idea, it adds complexity.
* Daniel Huigens (DH): AEAD was changed because of a downgrade attack designed from Lara Bruseghini, converting GCM to CFB if the MDC is broken, leading to a decryption oracle. Therefore we added key separation. There are other possibilities, but changes were needed.
* WK: Better option is to only allow one mode of operation, which should be OCB. Rather add an optional GCM packet rather than deprecating the old one.
* Daniel Kahn Gillmor (DKG): Less is better, but changing the mode to OCB only is a major change already.
* WK: Users should have choice of algorithm but not mode.
* Paul Wouters (PW): This is an argument for discussion before we make a PR.
* Justus Winter (JW): check with Werner to define a more precise proposal and discuss this on the mailing list.

Action on chairs: Start thread on mailing list to discuss whether people prefer the changes to modes of operation in -05 or Werner's proposal.

Issues/Merge Requests for Discussion

Certificate structure

Daniel Huigens
* There has been discussion and proposals in the design team about dropping userIDs. There is a convention to require userIDs where you store information about the key itself (e.g. Expiration date, Preferred algorithms). There are use cases where a key without userIDs is useful for privacy reasons.
* Crypto refresh does not require neither an UserID nor a self-signature.
* Do we need an userID?
* We need a separate mechanism to verify its authenticity
* Someone could "steal" a key and claim it is theirs if it had no userID
* In general there are not many crypto reasons to include an userID
* Do we need to require a direct self-signature?
* We need to store some information about keys (e.g. expiration or algorithm preferences), that an attacker should not be able to strip
* Tentative proposal (for v5 keys):
* Make userIDs optional (as the current draft does) but require a direct self-sig.
* If we need sender identity sign it as part of the message.
* Is this even in charter? Defining it now would make the v5 certificate structure clearer.
* Do we care about userID specific preferences? Separate keys should be generated for different purposes.
* Do we care about PGP/inline if the sender is not signed? use the Signer's userID should be used.

* DKG: Complexity of per userID preferences is a lot, and this proposal makes implementation easier. Have not encountered a case where this per userID prefrences added value.
* WK: We should still require a userID, except for specialized situations where there's no room for them.
* DH: RFC4880 required an userID packet but not a self-signature on it, and it would be meaningless without.

Action for chairs: Start thread on the mailing list to discuss preference between a) the tentative proposal for v5 keys (see above) or b) the status quo (possibly better documented).

KeyIDs and fingerprints

We have developed several solutions to compare key authenticity but none really worked so far. Either we have a keyID that is too short for security or a fingerprint that is too large for human use.
* DKG: I don't think there is any concern for in-the wire replacement of keys. Fingerprints should be compared from a computer. No solution is proposed if humans are in the loop for verifying keys.
* Maarten Aertsen (MA): Should competing/differing implementation arise on the UX level? Would having multiple bad solutions a better way?
* DH: We shouldn't show fingerprints to the user, and we should come up with some visual solution to display this information to the user. This should be done in a separate specification, in order to keep room ro solve the problem more broadly
* Mallory Knodel: It might be worth looking at how direct messaging tackled the problem, and adopt a similar solution.
* MA: It is understandable why not making a choice here and postponing this to another, separate spec.
* Stephen Farrell (SF): Is the conclusion that we should not recommend a particular form but perhaps we should look at messaging solutions to see how they've soved the problem?
* PW: When we re-charter we should include this topic
* SF: Argues against making solving this now a dependency for re-chartering
* DKG: Specifying which part of the fingerprint to show might be in charter
* Roman Danyliw: I will be responsible SEC AD for this WG. I'd like the technical discussion to continue but I'd like to postpone the in scope/out of scope discussion for a later date.


Sha-1 is on the way out, shall we recommend to use a collision resistant sha1 implementation? sha1collisiondetect is SHA1 except during know collisions. This might make implementations break. Just want to flag that sha1collisiondetect is there.
SF: We can raise this as a thread on the mailing list and see if people want to go this way.
Action: Chairs: Create a thread on this topic (use of sha1collisiondetect as opposed to SHA1)

Next Steps

  • PW is going to be SEC AD so will have fewer cycles for openpgp.
  • Many issues, but not so many open PRs
  • Closing the last open issues presented today before going in last call

Other Presentations

A post-quantum approach for openpgp -- Standardization efforts for PQC in OpenPGP in PQC@Thunderbird

Falko Strenzke
* BSI project, standardisation of PQC in OpenPGP. Implementation of proof-of-concept multi-algorithm KEM and signature (lattice based) in Thunderbird (Botan) and in GnuPG/Libgcrypt
* Motivation - from KEMs store now and decrypt later, need long term security for signatures. Demand for PQC observed in field.
* There are several projects already starting with PQC standardisation.
* Design criteria - hybrid (classic + PQC) for public keys, KEM construction, signatures. Orientation to existing protocols/standards. Want backwards compatibility - want new formats to be processable by existing implementations.
* Timeline - target to produce first draft in Q4 2022. Efforts will last until end of the project.
* Open for any input or contribution from the WG. Plan to work on a draft for later adoption by the WG (not in scope of charter at the minute).


  • Florence D (FD): Have you given any thought to algorithms yet?
  • FS: We plan on considering all the schemes standardised by NIST, but sticking to only one KEM and one signature algorithm
  • Aron Wussler: We (ProtonMail) are also planning to create an experimental implementation, proposed algorithms look good, we'd like to have a chat to ensure interoperability

End-to-end encryption definition -- draft-knodel-e2ee-definition

Mallory Knodel
* Goal - definition of end-to-end encryption (e2ee) communications/systems. Aim is to make it more difficult to call things e2ee which aren't e2ee. Question: is it a desirable thing to articulate a norms/principles driven approach to e2ee?
* Has been presented to a few different groups in IETF back to IETF 111. Mailing list is
* Avoid providing an anti-definition, where we define what e2ee is not.
* Table of contents: three part draft 1. formal definition 2. system design (features/challenges) 3. user expectations.
* Changes since -00, -01
* Future of the draft (options for review) - protection of metadata section, more ideas around forward secrecy and backwards security, check deniability considerations.
* Call for more reviews. Work happening on github ( or email the mailing list
* Encouraging people to read the draft.

Key transparency

Aron Wussler
* Project that protonmail have been developing recently. Allows user to verify other users' keys cryptographically.
* Particularly relevant for WKD.
* Currently we typically either have a key signing party or a web of trust. Would like to propose an automatic alternative.
* How it works: Implemented using a Merkle Tree for a Key Transparency log. Keys are added to the log, when you request a key you receive information from that log e.g. epoch hash with proof. You can check that the same data is provided to all parties. Auditors can verify that the tree is consistent.
* Currently protonmail retains that log, but anyone could run one.

* DKG: Why are fingerprints at the leaves of the trees as opposed to full certificates? There are possible attacks with a malicious WKD server.
* AW: This is a toy example. In final implementation we include sub key fingerprints and key usage at tree leaves.
* DKG: Do we need a whole new data format?
* AW: If we can get this into an RFC we won't use proprietary standard, will work with community to find what's needed.
* DKG: Would be good to know what you need which can't be included in the existing certificate format.
* PW: How do I know that entries in the key are real and not fake?
* PW: Who controls the domain? You could also put key in DNS and protect it with DNSSEC.
* AW: This approach allows you to look into the past and see what's changed. Also to see if anyone has published a key on your behalf.