Skip to main content

Minutes IETF116: openpgp: Wed 06:30

Meeting Minutes Open Specification for Pretty Good Privacy (openpgp) WG
Date and time 2023-03-29 06:30
Title Minutes IETF116: openpgp: Wed 06:30
State Active
Other versions markdown
Last updated 2023-03-29


IETF-116 OpenPGP WG Meeting

Wed, March 29, 1530-1700 local (Asia/Tokyo), 0600-0800 UTC

Notetaker: Jonathan Hammell

Agenda Bash

  • no bashing
  • Stephen Farrell (chair): plan is that after this meeting, there will
    be another revision of the crypto-refresh draft, then go for

Crypto-refresh issues (Daniel Khan Gillmor)

  • outline of changes since draft -07
  • a couple changes in the git repo since draft -08

New algorithm IDs for the CFRG algorithms in OpenPGP (Daniel Huigens)

  • OpenPGP used weird OIDs for Curve25519
  • recent interest on switching to the X.509 OIDs
  • using new algorithm IDs instead to take the opportunity to clean up
    the usage of Curve25519 in OpenPGP
  • No MPIs (native encoding on the wire), no checksum (AES-KW already
    has one), and no padding (for v6 PKESK)
  • draft -08 uses an ad hoc padding scheme to work with v3 PKESK (which
    includes the symmetric algorithm ID in the session key)
  • the version on git instead leaves the symmetric algorithm ID
    unencrypted, since hiding it doesn't add much
  • leaving it unencrypted could lead to cross-algorithm attacks

    • mandate use of AES?
  • need the Intended Recipient Fingerprint signature subpacket to bind
    the recipient fingerprint

  • Stephen: what is the state of this? In a MR?

    • Daniel: Most of it is in git, will make a MR for mandating AES
      if everyone agrees
  • Stephen: What do you mean by mandating use of AES

    • Daniel: If you are encrypting to multiple keys (one of these new
      one and a legacy one), then you have to leave the symmetric alg
      ID unencrypted. But then someone could change the symmetric alg
      ID. So we mandate the use of AES, so an implementation can
      reject messages encrypted with another algorithm
    • DKG: if you are encrypting to a new key with an old style of
      encryption, then you should use AES as the symmetric cipher to
      avoid the potential of a cross protocol attack.
  • DKG: Daniel, will you put a MR and send to the Mailing List.

    • Daniel: Will do.
  • Joris Baum: Wouldn't this mean to cover the corner-case is to
    require AES always?

    • Daniel: Question is whether we mandate it always or only in the
      corner-case. Implementations have a choice.
  • Falko Strenke: The corner-case is unlikely.

    • Daniel: I agree.
  • DKG: If you are in the niche corner-case, you likely want to use AES

  • DKG: Make the MR as minimal and clear as possible.
  • Stavros Kousidis: The key derivation just takes the shared key, it
    doesn't take the ephemeral point? There is an option in the RFC for
    parties to use the ephemeral components in the KDF.

    • Daniel: We just are using the shared key.
    • DKG: Should the current implementation change?
    • Stavros: From my point of view, yes. But I don't want to delay
      the process. The change shouldn't be heavy. The reason behind it
      is the HKDF is CCA-secure. Noted in the RFC that specifies the
    • Daniel: If we have the intended recipient fingerprints in the
      signature, do you get the same properties?
    • Stavros: Not sure.
    • Daniel: There is a downside of doing this to automatic
    • Aron Wussler: It boils down to whether you want CCA2 security.
      Maybe relevant for a smartcard use case, but for more cases it
      is not.
    • Stephen: This is a change we could do, but it would add another
      couple of weeks for discussion. Is anyone really pressing for
      this change now?

      • Stavros: I'm not pushing on this.
      • Roman: The WG cannot recharter until the refresh is done.
    • DKG: If the change is made, would anyone object?

      • Aron: I would be happier without it, due to impact to
        forwarding and the delay.
    • Stephen: I think that the it seems we should not do this change.
      But anyone who strongly believes in it should comment on the
      mailing list.

  • Daniel will make a MR (not including changing the KDF inputs) and
    post to the mailing list.

Outstanding Merge Requests (dkg)

  • MR !268 (Subpacket Criticality)
  • MR !269 (Primary Keys MUST be able to sign)
  • MR !271 (SHOULD implement subpackets)
  • MR !272 (Clarify self-sig guidance)
  • MR !273 (Clean up Notation registries)
  • MR !228 (Session Key Reuse) - more later
  • MRs for test vectors
  • MR !223 (Remove checksum+padding from v6 ECDH)

    • maybe not needed with CFRG curves
    • Stephen: clarification, will this MR be dropped?

      • DKG: yes
    • DKG: merging it will make a wire format change

    • no objection

Security Considerations for Session Key Reuse (Falko Strenzke)

  • session key reuse (SKR) mechanism allows reply using only symmetric
    encryption with key derived with a new salt
  • pitfall 1: replying to only a subset of the original recipients
  • pitfall 1a: special case where attacker removes themselves from the
    recipient list
  • pitfall 2: replying to more than the original recipients
  • pitfall 2a: save the message, then add more recipients
  • pitfall 3: interfering session key reuse
  • interoperability can be a problem between clients that have
    differing support
  • Security Considerations section documents these pitfalls and
    provides SKR guidance
  • Stephen: Where is this? Merged?

    • DKG: In a MR, but not merged yet
  • no objections

  • Stephen: MR should be merged

Next Steps

  • Stephen: Any objection to submitting draft -09 for publication in
    the next couple weeks after the MRs are merged?
  • no objections raised


Stateless OpenPGP CLI update (Daniel Khan Gillmor)

  • profile option for generate-key and encrypt

Interop test suite update (Justus Winter)

  • Stephen: Thanks for all that interop work.

Re-chartering topics

  • Stephen: topics came from mailing list, email to chairs, and gitlab
  • Stephen: Join the queue if anyone has opinions on what is your top
    two topics

Summary of various topics

  • PQC (Falko Strenzke)
  • Automatic Forwarding (Aron Wussler)
  • Key Superseded (Aron Wussler)
  • Replacement for Designated Revoker (dkg)
  • User ID clarifications (dkg)
  • Attestation Signatures, a.k.a. "1PA3PC" (dkg)
  • WoT: Trust Signatures, Regex subpackets, Validation constraints,
    Certification capable subkeys (dkg)
  • Stateless OpenPGP Interface ("SOP") (dkg)
  • Reusing session keys in a specific application layer: E-mail
  • PGP/MIME guidance for v6 signatures
  • Various (Daniel Huigens)

    • Long-term symmetric keys (Daniel presented on at IETF 114)
    • Forward secrecy (possibly mostly covered by short-term keys +
      re-encryption using long-term symmetric keys, but might still be
      worth discussing separately, to see if we want a more "proper"
      solution like double ratcheting)
    • Domain separation
    • Key verification, e.g. a better alternative to manually
      verifying fingerprints. This topic could include using QR codes
      or similar, or even something like Key Transparency to
      automatically verify keys (which Aron presented on at IETF 113).
  • Daniel: I agree PQC should be the top priority. Automatic forwarding
    is also important and interesting. Long-term symmetric keys would be
    useful for encrypting data only for yourself. Long-term symmetric
    keys is the most important in my topics. Domain separation should be
    easy. Forward secrecy has been an issue for a while.

  • Stephen: It seems there is consensus to do PQC. So no need to
    indicate it.

  • Justus Winter: We want a way to share certificates and trust roots
    between implementations.

    • Stephen: Is there an existing issue with this.
    • Justus: We started writing a draft on this and happy to bring it
  • Justus: Would like see semantics for issuing certificates

    • DKG: Is there a draft? It would be easier to discuss.
    • Justus: I don't think it has been written down.
    • Justus will create an issue in gitlab.
  • Stephen: Is it wrong to suggest that this list (with Justus's
    additions) is a superset of what we want to do?

    • no objects
  • Stephen: Most topics are concrete, except for fingerprints.

  • Aron Wussler: Also for key superseded, we have proposed one way but
    there are other options.
  • DKG: Is WKD something you would like to consider?

    • Aron: On would like to see it, but not volunteer for it.
  • Roman: The KeyTrans BoF seemed to have general agreement and
    interest in doing work. Will result in producing a charter. Nothing
    jumps out as overlap.

  • Roman: I think OpenPGP should move forward and not lose the
  • Justus: Representation of trust semantics could be another topic.
  • Aron: What we produce should be aligned with KeyTrans. So we may
    need to wait until they proceed.
  • Daniel: WKD is mostly done since it is being used. But may be
    valuable to have as a formal RFC.

  • Stephen: Will schedule a virtual interim to discuss chartering
    topics after the crypto-refresh is submitted.

  • DKG: Gitlab admin repo has existing charter.
  • Stephen: Consider the topics in the meantime.
  • DKG: Clearest way to demonstrate interest is to write an individual
    draft on the topic.

  • Roman: I want to applaud the WG on getting to the finish line.