Subject: Re: [openpgp] [[email-masked]] New Version Notification for draft-ietf-openpgp-rfc4880bis-10.txt

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Sep 2020 12:49:34 -0400 (EDT)

On Mon, 31 Aug 2020, Werner Koch wrote:

Hi Werner,

> expiration date was close so I uploded a new revision.  Collected
> changes from the repo since -09 are:
>
> b5c48cf Clarify the use of the 2 hash octets in Signature Packets.
> 750b19f Fix signature packet description for EdDSA
> 6c0bd58 Add existing value to list of User Attribute Types.
> 76177bb Use consistent capitalization for User ID and User Attribute.
> 722ed9e Typo fix

These makes sense.

> 30d8397 Introduce the Key Block subpacket to align OpenPGP with CMS.

> 6fd718d Revert to the RFC4880 requirement of having a User ID.

Were these two changes the result of consensus on the list ?

Paul

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 2 Sep 2020 13:01:09 -0400

Paul,

> Were these two changes the result of consensus on the list ?

I don't know about the former; the latter was mostly consensus.  I think I
was the only major objection to it.  It's possible that Jon Callas also
objected at the time, but I don't recall.  Pretty much everyone else
didn't care or wanted to revert this change (which I introduced).  But
honestly, right now, it doesn't make a difference to me either way so I'm
fine with reverting this.  We wound up using a different path for images
and decided to include it by reference using a hash-attribute instead of
by value in an image-attribute, so not using the attribute as originally
designed.  So this reversal doesn't break our code.

> Paul

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Werner Koch <[email-masked]>
Date: Wed, 02 Sep 2020 20:00:49 +0200

> I don't know about the former; the latter was mostly consensus.  I think I

The former was proposed a couple of years ago and iirc, I was a major
voice against.  Meanwhile, afterh the meltdown of the keyserver network
we should bite the bullet an do it like it has always been done in CMS.

Better have a dedicated subpacket than having everyone squeezing it into
a proprietary notation.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Sep 2020 14:48:00 -0400 (EDT)

> Better have a dedicated subpacket than having everyone squeezing it into

That does not answer my question though.

Was this discussed in the working group? Why was it changed now in this
revision. The reason I'm asking is because people have said in the past
that changes were introduced by an author without WG consensus, so I'd
like to know if these two material changes have seen proper discussion.

Paul

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 2 Sep 2020 14:59:34 -0400

Paul,

> like to know if these two material changes have seen proper discussion.

Small pedantic nit -- there is no WG, so technically there is no WG
consensus to be had.

Having said that, there was certainly discussion about the "revert to 4880
requirement for a user id packet" change.  I don't recall the other topic.

-derek

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 02 Sep 2020 22:05:36 +0200

Hi Derek,

On Wed, 02 Sep 2020 20:59:34 +0200,
> requirement for a user id packet" change.  I don't recall the other

As of draft 9 (published 9 March 2020) the User ID packet was still optional.
In draft 10 (published 31 August 2020) that change was reverted.

  https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-09#section-11.1
  https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#section-11.1

It was reverted specifically by this commit:

  Revert to the RFC4880 requirement of having a User ID.

  With the below referenced patch Derek Atkins integrated his
  "Device-Certificate Draft" to allow the use of a stripped down OpenPGP
  key by space constrained devices.  The draft was never meant as a
  general lifting of requirements which were intentionally introduced
  when formalizing the old PGP 2 formats as OpenPGP.  This patch
  clarifies this.

  https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/6fd718d39fc8db20e4731350899db1b7c48c721e

which was made on 12 March 2020.

Between January 25, 2020 and March 12, 2020, there was one mail to
this mailing list, which was a message from DKG about the stateless
openpgp cli.  I reviewed the archives from the past year, but I
couldn't find this discussed.  Did I miss something?

  https://mailarchive.ietf.org/arch/browse/openpgp/?

FWIW, my position and, as I understand it, Justus' and Vincent's is
that User IDs ought to be optional.  In fact, Hagrid is built around
that assumption, and Sequoia explicitly supports it.

Thanks,

Neal

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 2 Sep 2020 16:28:32 -0400

Hi Neal,

>   https://mailarchive.ietf.org/arch/browse/openpgp/?

There is a thread that started by Justus Winter on February 20, 2019,
Subject "User ID Attribute Subpacket", which began the conversation to
revert back to the RFC4880 definitions.  The thread kind of ended on March
8, 2019, but no changes were made to the draft at that time.  Search the
archive for "attribute" to easily find the thread.

My guess is that Werner took his time to update the spec based on the
conversations.

> that assumption, and Sequoia explicitly supports it.

That was not the conversation that was had, and Vincent was not involved
in the thread at all.  But then again re-reading this thread it was about
why have User-Id Attribute Subpacket in addition to the UserID packet.. 
It wasn't specifically about reverting the change to make UserIDs
optional.

-derek

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 02 Sep 2020 22:47:01 +0200

On Wed, 02 Sep 2020 22:28:32 +0200,
> archive for "attribute" to easily find the thread.

Thanks for digging this up.

> It wasn't specifically about reverting the change to make UserIDs

In that thread, Justus specifically talked about stripping User IDs:

  The only thing that having UserID subpackets for the User Attribute packet
  is that you can have multiple userids bound by one binding signature.  But
  that is a feature that I dislike, because then we can no longer strip down
  TPKs so that they only include a subset of the userids, which can enhance
  the privacy of our users.

  https://mailarchive.ietf.org/arch/msg/openpgp/peinz1RAzaSSgWWbP3-voM1IpOQ/

And:

  I support dropping the requirement of a UserID or UserAttribute packet.

  https://mailarchive.ietf.org/arch/msg/openpgp/51DeCO8jXvaKKzZiq1sKev-aZNw/

Thanks,

Neal

---

From: Vincent Breitmoser <[email-masked]>
Date: Wed, 02 Sep 2020 23:38:15 +0200

Hi Derek,

> Small pedantic nit -- there is no WG, so technically there is no WG

I have said it before, and will say again: This is a document published under
the ietf- namespace, it speaks with the authority of the working group. "There
is no WG, hence nothing matters and everything goes" is simply not a valid
argument.

For the record, I still stand by every word of <[email-masked]>

 - V

---

From: Vincent Breitmoser <[email-masked]>
Date: Wed, 02 Sep 2020 23:43:36 +0200

For the record, a relevant discussion about the UserID requirement on keys went
on over at https://dev.gnupg.org/T4393 on the GnuPG issue tracker. It's a pretty
informative read overall about the state of the community.

 - V

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Sep 2020 17:53:36 -0400 (EDT)

> Small pedantic nit -- there is no WG, so technically there is no WG

It was my understanding that there was some thought about re-opening it
to get the bis document out. But that WG chairs were needed. One issue
on re-opening would be how to handle the document author being one main
implementation author writing things that some felt did not have WG
consensus.

That is why I was asking this. I'd like to know if this an update from
Werner or an update from a consensus on this list - WG or no WG at the
moment.

Paul

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 2 Sep 2020 18:51:15 -0400

Vincent,

> is no WG, hence nothing matters and everything goes" is simply not a valid

You can say it until you are blue in the face, but there is no working
group with the authority to publish a document.  There is no active
charter.  There is no current WG Chair.  All we have is this list of the
remnants of the WG.

Now, if I were AD and asked to publish this document, I would absolutely
go look at this list archive to try to determine if there was consensus on
the mailing list for the document, but that does not a working-group make.

I'll also point out that there is no requirement for a standards-track
document to come out of a working group; an AD can sponsor it.  And
indeed, that would be my expectation for 4880bis.  However, technically,
Werner has the right to do as he pleases because, as I've said before,
there is no working group.  Also, technically, anyone else could take up
the reigns and create an alternative 4880bis.

> informative read overall about the state of the community.

If you want to talk about working group consensus, THAT is definitely NOT
a place where WG Consensus can or should happen.  That is the area for one
specific OpenPGP implementation; so once GnuPG had some consensus on the
matter, by your own admission that should have been brought here for open
discussion among the remnants of the OpenPGP Working Group.  You can't
have it both ways.

IMHO, that conversation should have been had on this list prior to the
draft being updated.

On Wed, September 2, 2020 5:53 pm, Paul Wouters wrote:
> Werner or an update from a consensus on this list - WG or no WG at the

My understanding is that by definition it is an individual submission by
Werner which is *supposed* to have general consensus of the members of
this list. But "legally" there is no requirement that there be list
consensus at this point because there is no active working group so,
technically, it's an individual submission that would be AD-sponsored.

Having said that, I would *hope* that there were at least rough consensus
from this list before changes were made, but I know that hasn't happened
for all changes.

As for re-opening the WG (yet again), I'll just remind you that it was
closed specifically because it did NOT make progress on 4880bis, so I
don't know how re-opening it would change the velocity of the work.  The
only changes I can see happening would be having a chair that can declare
(rough) consensus on a topic and manage the changes asked from the Editor
(whether that continues to be Werner or changes to someone else), and it
would also require all consensus-building to happen on this list (or the
official WG list), and not on the list of a particular implementation.

Thanks,

-derek

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 03 Sep 2020 11:28:36 +0200

Derek,

> However, technically, Werner has the right to do as he pleases because, as
> I've said before, there is no working group.  Also, technically, anyone else
> could take up the reigns and create an alternative 4880bis.

I don't understand how any other course of action besides "it's closed,
therefore we can't publish under that namespace" could be valid here. Apparently
we are going with "it's closed, therefore anyone can publish whatever they want,
even if their integrity as an editor has been actively contested".

> a place where WG Consensus can or should happen.

Agreed. I only brought it up as informative.

> IMHO, that conversation should have been had on this list prior to the

Also agreed. But it didn't. Perhaps we should think about why that is, and work
towards changing it.

 - V

---

From: Ronald Tse <[email-masked]>
Date: Thu, 3 Sep 2020 09:46:57 +0000

Hi all,

For the record, there was never a consensus that Werner was “active contested” as editor of 4880bis. The contesting came from a relatively small group of contributors.

Not that I count for much, but Werner certainly has my support to continue editorship of the document, and from what I know a number of "former WG” members feel similarly (since there is no more WG).

Kind regards,
Ron

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 03 Sep 2020 12:09:12 +0200

Hi Ronald,

> For the record, there was never a consensus that Werner was “active contested” as editor of 4880bis.

Acknowledged. Of course, it is the nature of contested things that there is no
consensus. That's why they are contested. ;)

> The contesting came from a relatively small group of contributors.

I suspect it feels like that from both sides. I had talked to several folks in
person and online, and sent a draft for comments to at least six active openpgp
community members. My impression was (is) that the group is not "relatively
small", otherwise I wouldn't have sent the message.  However I have no numbers
on this, and the set of people I talked to is certainly biased, so it's entirely
possible that I'm wrong.

I will admit that the resonance on-list (I received a couple of supportive mails
off-list) was rather more lukewarm than I had hoped, which is why I didn't push
further. I only chimed in here because the topic of list consensus was brought
up, I'll try and drop it again.

> Not that I count for much

Of course you count :) By the way, congratulations on Thunderbird's decision to
use RNP as an OpenPGP library. I'm glad they did.

 - V

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 3 Sep 2020 08:06:37 -0400

Hi,

On Thu, September 3, 2020 5:28 am, Vincent Breitmoser wrote:
> therefore we can't publish under that namespace" could be valid here.

Because that's not how the process works.  If there is no active WG on a
topic, then the IESG can publish a document as a standards-track document,
even one that updates one created by a WG.  This is the situation that
OpenPGP is in right now, an AD would sponsor the draft to progress it
through the process.  Any objections would have to be made during the IESG
review process.

> Apparently

This is, unfortunately, true -- with the caveat that the IESG can still
block a document from being published.  Keep in mind that your final
phrase "integrity as an editor..." does not apply to what is, effectively,
an individual submission.

I think the issue is that while the DataTracker has a process to lift a
document from individual to WG draft, there is no process to "downgrade" a
WG document back to an individual document if the WG closes and they want
to continue working on the document -- which is what happened here.

In other words, you cannot think of this as a WG document, it's a
mis-named individual draft with the expectation that an AD will take it up
and progress it as a standards document.

> Also agreed. But it didn't. Perhaps we should think about why that is, and

Honestly, I don't know why the conversation didn't happen on this list,
and yes, that does bother me if the goal is to try to maintain some level
of rough consensus on the remnants of the OpenPGP WG membership (which is
here, not on the gnupg lists).

-derek

---

From: Werner Koch <[email-masked]>
Date: Thu, 03 Sep 2020 14:33:43 +0200

> Werner or an update from a consensus on this list - WG or no WG at the

It is part of the deployed GnuPG anyway and thus I feel it makes sense
to have this in the I-D.  Feel free to start a discussion again and if
there is no consensus we need to set the used flag to "reserved" as we
did in the past for features from PGP.

Shalom-Salam,

   Werner

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Sep 2020 09:01:05 -0400

> did in the past for features from PGP.

If the change is an optional feature that people don’t need to build support for, and causes no security issues for those not implementing it, I have no objection.

Note that I asked my original question in the hopes that people are still trying to reach consensus - I have no personal interest in any of the specific changes from the last draft. I was trying to get an email confirmation about the changes to prevent a further discussion far in the future about these changes.

So perhaps for clarity I should ask if there is anyone objecting to the changes in the latest -10 draft ? So far I got the impression that is actually resolved a previous unresolved issue and no one objects? Please correct me if I am wrong.

Paul

---

From: "Neal H. Walfield" <[email-masked]>
Date: Thu, 03 Sep 2020 17:05:38 +0200

On Thu, 03 Sep 2020 15:01:05 +0200,

I have an issue with the first change here:

    -    included in the Signature packet to provide a quick test to reject
    -    some invalid signatures.
    +    included in the Signature packet to provide a way to reject
    +    invalid signatures without performing a signature verification.

I think we should leave the "some" as just checking the hash prefix is
not equivalent to "performing a signature verification", which the new
text seem to suggest.

I don't object to the rest.

I don't understand this enough to judge.

Assuming that we add support for the User ID Attribute Subpacket, I'm
fine with this change.

No objection.

  722ed9e Typo fix

No objection.

I think the idea is okay, but the execution (what should and should
not be included) could use some work.

  669f73f Typo fix

No objection.

I disagree.

---

From: Werner Koch <[email-masked]>
Date: Thu, 03 Sep 2020 17:36:55 +0200

> not equivalent to "performing a signature verification", which the new

Done in the repo.  Thanks.

Shalom-Salam,

   Werner

---

From: Justus Winter <[email-masked]>
Date: Tue, 15 Sep 2020 10:33:19 +0200

> not be included) could use some work.

Even though I initially proposed it, I now have my doubts about the
design and would have appreciated a discussion on this list first.

The problem I see is that the size of a subpacket area is limited to
1<<16 bytes.  This severely limits the number of certificates that can
be communicated with this mechanism.

For example, the Bob sample key (D1A6 6E1A 23B1 82C9 980F 788C FBFC C82A
015E 7330) measures 1741 bytes, meaning we could fit 37 of those into a
subpacket area.  On the other hand, my cert weighs in at 9148 bytes,
bringing this number down to 7.

Now, these are both certificates with RSA keys and signatures, and the
numbers are way better with ECC.  But, we don't know how large PQ keys
and signatures will be.  Notably, if the cryptographic community settles
on McEliece, we will not be able to fit a single key, let alone a
certificate, into a subpacket area.

So, the design has severe limits given current certificates, and may
become completely unusable in the near future.  Therefore, I believe we
should find a better solution.

Justus

---

From: "Neal H. Walfield" <[email-masked]>
Date: Tue, 15 Sep 2020 11:36:29 +0200

On Tue, 15 Sep 2020 10:33:19 +0200,
> design and would have appreciated a discussion on this list first.

I agree with you Justus, but I don't see the situation quite as dire
as you.

> be communicated with this mechanism.

PQ keys are still a ways off.  One approach to workaround this
limitation would be to raise the maximum size of the subpacket areas
for v5 signatures *now*.  This is relatively straightforward.

> certificate, into a subpacket area.

These certificates can be minimized.  Using gpg's export minimal
option, I get 6521 bytes for your key:

  $ sq keyserver get 0x9B7DD433F254904A | gpg --import; gpg --export-options export-minimal --export 0x9B7DD433F254904A | wc -c

Inspecting the minimal key, I see that there is still a fair amount
that can be stripped:

  $ gpg --export-options export-minimal --export 0x9B7DD433F254904A | sq inspect
  -: OpenPGP Certificate.

      Fingerprint: CBCD 8F03 0588 653E EDD7  E265 9B7D D433 F254 904A
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 4064 bits
    Creation time: 2017-07-19 16:28:55 UTC
  Expiration time: 2022-07-18 16:28:55 UTC (creation time + P1825D)
        Key flags: certification

           Subkey: A7E0 0611 1566 B481 A1FE  04CF C471 3E5A A93F 9D68
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 2048 bits
    Creation time: 2017-07-19 16:36:26 UTC
  Expiration time: 2022-07-25 15:31:26 UTC (creation time + P1831DT82500S)
        Key flags: authentication

           Subkey: 256A 4E55 E4A7 2D97 AD24  68E7 88DC 7E33 385F 791D
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 2048 bits
    Creation time: 2017-07-19 16:32:31 UTC
  Expiration time: 2022-07-25 15:31:26 UTC (creation time + P1831DT82735S)
        Key flags: signing

           Subkey: 0628 A563 C5F2 D310 7D6C  9574 08CC 70F8 D8CC 765A
  Public-key algo: RSA (Encrypt or Sign)
  Public-key size: 2048 bits
    Creation time: 2017-07-19 16:34:06 UTC
  Expiration time: 2022-07-25 15:31:26 UTC (creation time + P1831DT82640S)
        Key flags: transport encryption, data-at-rest encryption

           UserID: Justus Winter <[email-masked]>

           UserID: Justus Winter <[email-masked]>

           UserID: Justus Winter <[email-masked]>

           UserID: Justus Winter <[email-masked]>

           UserID: Justus Winter <[email-masked]>

Clearly, the authentication subkey can go, as can all but one of the
user ids and their self-signatures.

But, let's think about what we *really* need.  Let's say I send you
and Alice a message and Alice wants to reply to all.  In that case,
Alice only needs our encryption subkeys.  Really.  In the context of
the thread, it is reasonable for Alice to use the same keys as I use;
my signature (this subpacket is in the hashed area!) is a de facto
certification that the keys should be used for this group
conversation.  (My signature binds the thread and the set of keys.)

So all Alice really needs is a list of the encryption subkeys.  Alice
doesn't need your signing subkey, because she is not verifying a
signature from you; she only needs my signing subkey.  In fact, she
doesn't need your signing key until you send a message, which you, as
the sender, can include!

(Admittedly, it is useful to include the primary key so that when
Alice replies, you can verify that it was signed with a key that I
authenticated for the purpose of this thread.)

What about the certificate's preferences?  Well, Alice can infer a
reasonable set of preferences by simply copying the preferences that I
used.  (Neal encrypted the message using AES-128 and the signature
used SHA-256, ok, I'll do the same.)

What she might need is the expiration time, but my implementation
compute the minimum over all keys and store that in the Key Expiration
Time subpacket of my signature.

What happens if Alice wants to remove someone from cc?  Well, we could
include a User ID.  If we don't add the self-signature this normally
only adds a few dozen bytes.  (Note: if not including the primary key
is too extreme, because you really want something that looks like a
TPK, 4880 doesn't require that a User ID in a TPK have a self
signature [1].)

  [1] https://tools.ietf.org/html/rfc4880#section-11.1

Let's do a bit of math.  A 4k RSA key, which is the worst case right
now, requires:

  Key: ~272 bytes
  Signature: ~571 bytes

So, for a minimal valid TPK, we have:

  [ Primary ] [ Direct Sig ] [ User ID ] [ Subkey ] [ Self sig ]

  272 + 571 + 24 + 272 + 571 = 1710 bytes

or:

  [ Primary ] [ User ID ] [ Self sig ] [ Subkey ] [ Self sig ]

  272 + 24 + 571 + 272 + 571 = 1710 bytes

This allows for 38 recipients in cc.  For most group chats, 38
participants is probably enough.  If you have more, then it is
probably a broadcast.  That is, replies are not expected, and then you
can just elide most of this.

But, using the more extreme variant that I proposed above, we only
need:

  [ User ID ] [ Subkey ]

  20 + 272 = 292 bytes

which allows for about 292 recipients.

Neal

---

From: Justus Winter <[email-masked]>
Date: Tue, 15 Sep 2020 12:16:01 +0200

> for v5 signatures *now*.  This is relatively straightforward.

PQ keys being way off doesn't mean it is a good idea to come up with
features now that may stop working when PQ gets here.

Raising the maximum subpacket area size may help, but brings its own
problems, like increasing the size of signatures that need to be kept in
memory.  Also, fundamentally, the problem is trying to stuff an object
with a fixed upper size into an object of the same kind.  Think my
binding signature carries an embedded certificate for a third-party
revoker, which may have a third-party revoker, etc.

> option, I get 6521 bytes for your key:

Indeed, I missed some old subkey binding signatures when calculating the
size.

> Inspecting the minimal key, I see that there is still a fair amount

That seems to help for the very narrow use case of replying to all
recipients, but then it is no longer a replacement for keyservers.
I read Werner's comment that the proposed subpacket is a way to gossip
key updates around:

> Meanwhile, afterh the meltdown of the keyserver network we should bite
> the bullet an do it like it has always been done in CMS.

> can just elide most of this.

Me and my 44 delta.chat friends in one group like to disagree.

> which allows for about 292 recipients.

Extreme :) but what if I have more than one encryption subkey for
different purposes or to support different algorithms?  Further, I don't
think this extreme stripping was envisioned when the subpacket was
introduced.

Justus

---

From: "Neal H. Walfield" <[email-masked]>
Date: Tue, 15 Sep 2020 13:29:28 +0200

On Tue, 15 Sep 2020 12:16:01 +0200,
> features now that may stop working when PQ gets here.

The sun will explode.  But, I'm still making plans for the future.

Every measure is a stopgap solution.  And, I think if we continue to
push the ecosystem forward, we'll find other solutions that even if
they don't supersede this one are at least complementary.  So, I think
it is worth thinking about this solution, even if it is not as general
as we might like.

> recipients, but then it is no longer a replacement for keyservers.

Indeed.

> I read Werner's comment that the proposed subpacket is a way to gossip

I disagree that keyservers are going to die.  Even signal has key
servers (and, think about all of the prekeys).

> Me and my 44 delta.chat friends in one group like to disagree.

These days, delta.chat generates ecc keys :D.

  https://delta.chat/en/2020-05-27-may-features

> different purposes or to support different algorithms?

If your policy is to encrypt to all encryption-capable subkeys, then I
say: include them all.  Currently, there is neither a de jure nor de
facto standard here.

> Further, I don't

  > not be included) could use some work.

:) Neal

---

From: Phil Pennock <[email-masked]>
Date: Tue, 15 Sep 2020 19:37:07 -0400

> The sun will explode.  But, I'm still making plans for the future.

Indeed, just because a wire size limit is raised to 32 bits, that
doesn't mean apps should accept and read into memory up to 4 GiB of data
as a key.

Surely the sensible approach is to raise the size limit in the packet
structure now, so that we don't need to change yet again, but advise
implementers to think about reasonable limits and perhaps default to a
16-bit 64KiB limit unless and until cryptographic suites come along
which _need_ higher.  Folks will need to update their software to
implement the algorithm anyway, so raising the parsed limit at that time
makes sense, and implementers should also be guided to skip past
subpackets for unimplemented crypto instead, so that they soft-skip
instead of aborting on larger packets.

It might even be worth example large packets for conformance testing, to
make sure they're handled gracefully?

> servers (and, think about all of the prekeys).

And this one is the reason for my speaking up: I think that there are
two different definitions of keyserver being used here.  I also think it
important to understand the status because it explains the assumptions
which client implementations will need to make.

In the sense of some abstract entity you go to, to retrieve keys,
keyservers are a solid design choice.  Nothing will kill that approach.

In the sense of the current reconciling network of OpenPGP keyservers,
using the SKS reconciliation algorithm, as implemented by SKS and
HockeyPuck, using an append-only data store for whatever data people try
to put into it, and traditionally run by volunteers: those keyservers
are dying.

When I ran one, there were routinely over 100 active keyservers
available for the pool selection algorithm to select from, and our work
on debugging, interop, and performance issues had resulted in
operational guidance which got the keyserver network to become reliable
enough that people once more started taking it for granted.

There are now fewer than 20 keyservers in the pool, 12 of which are run
by 5 operators (and over IPv6, 6/10 servers are from just 2 operators).
Reliability is now frustratingly low.  The pathology leading to this is
probably off-topic for this list.

The keyserver design approaches available which implementers should
account for, IMO:

 1. Validating non-synchronising keyservers, which require people to
    account for each one and choose to publish to it; the Sequoia-based
    https://keys.openpgp.org/ is a good example here, I use it, it does
    not fill all the old use-cases but it works for what it does, is
    performant, and is as close as we have today to "central keyserver"
    plus "reliable (within constraints)".
 2. <https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore>
    Dan Gillmor's Abuse-Resistant Keystore spec is probably required
    reading for anyone thinking of implementing any kind of keyserver.
    Even if we don't get new peering keyservers out of it, the
    terminology and profiles it defines are important for being able to
    clearly communicate what folks are trying to achieve.
 3. Federation, with a keyserver per domain, perhaps outsourced to
    central servers; WKD is probably the sanest path forward here:
    <https://tools.ietf.org/html/draft-koch-openpgp-webkey-service>
    since it doesn't require updating DNS for each PGP key, and provides
    a read-only template HTTP schema along the lines of PKS.
    kernel.org, debian.org, various other OS distributions and software
    projects are implementing this today.

There are others, but those are the three sets which I think developers
of OpenPGP key-using software need to be familiar with before designing
their remote key management sub-systems.

-Phil