Re: [openpgp] OpenPGP interim meeting tomorrow (2021-02-26 15:00Z)

Daniel Kahn Gillmor <> Mon, 15 March 2021 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E7A53A12E1 for <>; Mon, 15 Mar 2021 16:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=o6EPLAYR; dkim=pass (2048-bit key) header.b=0B2g3gIj
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ElEwgq70JbIz for <>; Mon, 15 Mar 2021 16:32:45 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9CAF3A12E2 for <>; Mon, 15 Mar 2021 16:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1615851161; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=yi9espowAuApzR2szPq06i4ibuL2UPPoPi0rCS5SFoI=; b=o6EPLAYRiy6PB+2wGbucxG9b4HujDs/nC5EahDH0oWpKqR8NdQmJo70kxrkl2J8tGcUbS PdndNv9lMNAUcggAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1615851161; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=yi9espowAuApzR2szPq06i4ibuL2UPPoPi0rCS5SFoI=; b=0B2g3gIj2hVshRPH3/jiC1ag+RSefEZAK5TuUi8DdyHkrOKkH54HoxYGveD92TJ7TTRxG UbCQmSrzZP0V+qdF+4DaKg9ts+GvHSYex3g2wDJyRNgEPMf1sO9yCZRMM8BERGFVT1qDzWR uaAIMp3UMzuVnIsdxbST6uY6cujHxyhp66sUCTwrlmJjRBd6xZA2fNXa1p09RQ2ExLm1tDw OQiDLtnZTNqQeTJnHHL9lF9wWMyYJV/QV5qqaIkP6bpAhEk4hark3kszOkl1LzZ3KrK+zU6 HDYYx19e7Aa/h/2tAF0Au+dlpm5EeHoIwsPDdyuZ6RBuLDJrol6dp/xx4P0w==
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 9DC33F9A5 for <>; Mon, 15 Mar 2021 19:32:41 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 44CAF204A0; Mon, 15 Mar 2021 19:09:48 -0400 (EDT)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Mon, 15 Mar 2021 19:09:46 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] OpenPGP interim meeting tomorrow (2021-02-26 15:00Z)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Mar 2021 23:32:47 -0000

On Sat 2021-02-27 00:01:18 -0500, Daniel Kahn Gillmor wrote:
> I've cleaned and uploaded the notes here:

It occurs to me that I never posted the notes from the interim
specifically to the list.   I include them below, so that there's no
need to pull from the website if you don't want to.



IETF OpenPGP February 2021 Interim


Meeting held via

- Agenda Bash
- Progress on draft-ietf-openpgp-crypto-refresh
- Developing the draft
- Next steps on draft-ietf-openpgp-crypto-refresh
- IETF 110 Agenda & next Interim


- Stephen Farrell
- Neal H. Walfield
- Daniel Kahn Gillmor (dkg)
- Paul Wouters
- Ángel González
- Werner Koch
- Vincent Breitmoser
- Friedel Ziegelmayer (dignifiedquire)
- Jonathan McDowell
- Sylvain Besençon
- Derek Atkins
- Andre Heinecke
- Christoph Biedl
- Andrew Gallagher
- Nora Widdecke
- Ben Kaduk
- Daniel Huigens
- Justus Winter
- Peter Yee
- Heiko Stamer
- Jonathan Hammell

Notes taken on [Riseup's

Primary Notetaker: Vincent Breitmoser

meeting begins: 16:04 UTC

chair intro, Stephen Farrell & dkg

## Agenda Bashing

no comments, moving on

(session recording starts late) naughty co-chair :-)

## Catchup for OpenPGP WG (dkg)

- rfc4880bis was running on its own, but with wg name
- plan was to recharter and restart wg
- over time restore changes from bis, establish consensus on individual diffs
- general updates about -00 to -02 of new doc [slides 4-5]

## Development status (dkg)

- draft development: now in markdown
- nitpicks can be given as merge requests, substantive changes need ML
discussion - issue tracker is ok, but do follow up on ML since it's the
canonical place - identical to rfc4880, as md - last
version of rfc4880bis draft, as md (historical reminder) -
working document

: additional comments from editors? (Paul & Werner)

no comments

## next steps, overview of diffs of bis to crypto-refresh

: [slide 7] changes split up into: chartered crypto-refresh changes,
crypto-refresh related, not crypto-refresh

daniel huigens
: intended recipient could be viewed as crypto-refresh to fix surreptitious
forwarding issue

: might want to promote? (...)

: brainpool curves are already in 6637, thus not relevant for crypto-refresh

: can't see them in 6637

: right. any curve can be used by oid, so still unnecessary

: perhaps just put in that info?

: support for crypto-refresh, and afterwards work on new draft. better not
discuss too much about what is and isn't in scope

: prefer not to go for another rfc. huge PITA certifying for new spec, would be
better to have this iteration suffice for the next 10 years derek : agree with
andre, for non-contentious issues we should include them even if not

: need to stick to charter. we can go beyond once that has been done
successfully. tried getting too much done before, couldn't focus enough on what
needed to be done. maybe other ways to handle certification issue?

: maybe include non-contentious issues that have no crypto implications? still,
important to stick to charter.

: IESG had a case or two where documents handed in exceeded charter. this
caused problems, should stay in charter at least for the next months.

: prefer to get document done quick and leave anything contentious to second
document, don't repeat previous cycle

(text werner)
: agree with paul

(text huigens)
: +1

(text friedel)
: +1

stephen & dkg
: anything missing from points? [slide 7]
  - no comments (feel free to bring to list)

: points on list [slide 7] might not mean we reach charter, might find

## beyond merge of 4880bis

: [slide 8] curve448? S2K update (argon2)? weren't possible in last iteration

(text daniel huigens)
: agree with those

### argon2

: argon2 makes no sense for openpgp. only makes sense if interoperable thus
would need to be mandatory, not good for argon2. code point ok, mandatory not
for openpgp.
  clarifications: symmetric encryption not primary use for openpgp, kdf not
  that important because symmetric use cases would use full entropy anyways

: s2k update important, use cases do exist

: fully disagree, symmetric crypto covers long retention, any change is API
breakage, introduces problems

(more back and forth andre/huigens)

: already have compat issues with pgp 2.6, bridge already crossed.

: no need to break old stuff when introducing new intro. having text to
consider would help the discussion. might be problem to introduce new algo
without guidance on when they may be used. no capabilities in symmetric

  by this reasoning, symmetric openpgp crypto is stuck and we can never change

: want algorithms in spec so we can switch when vulnerabilities occur. but is
painful for users, so must consider when we enforce it. no objections to
argon2, but don't want to switch default without attack scenario

: need specification yesterday on how to interpret, but don't generate.

(text andre)
: agreed

: create issue to track this issue

: argon2 has been discussed on ML, too. can't come to an agreement here, should
leave discussion for later

### curve448

: thoughts on curve448?

: gnupg has curve448. noticed that to do properly this in spec, need new data
type. that would take a while, maybe leave it out

## other updates?

: other updates for crypto-refresh, beyond bis?

: (on symmetric algos again), same issue with public keys (e.g. curve448).
needs way to use new algorithms while keeping compatibility

(text neal)
: not an issue because there is features subpacket

### userid-less keys

: regarding keys without user ids. seems huge split in community regarding this
issue, maybe we should discuss it?
  my opinion (as mail client implementor): no idea what should do with pgp keys
  without user ids. huge issue because this kind of key breaks my use cases.

: should create issue for that

: whole point of user id-less keys is so that you can get updates.

: I would like to clarify if it is legal to provide such keys.  I think it is
disallowed, but vincent is doing it anyway.  We should clarify this in the new

: I would also like the next RFC to clarify this.

: other similar use cases, e.g. free-floating revocation certificates. also not
specced but useful. might want to spec common formats that are in use, to give
better overview

: user ids without signatures are ok. hagrid could add "null" user id, so 4880
already addresses this

## Upcoming meetings

: registration for IETF 110 open [slide 9]
  - Meeting 2021-03-11 "Session II"

: waivers available. based on honor system, please don't abuse

: next interim? since IETF 111 is end of july. early may
  more frequent meetings possible. if we want that, should focus on specific

(text paul)
: early may sounds good

(text daniel huigens)
: might be useful to hold semi-regularly

: let's assume early may, confirm on list

: 4-6 weeks sounds reasonable

(sentiment that conferencing solution didn't work great, discussion about
alternatives on list)

meeting closed 16:07 UTC