[openpgp] Privacy-preserving Transferable Public Keys

[Vincent Breitmoser <[e-mail]>]

Hey folks,

following up on dkg's thoughts about abuse-resistant keyservers, I would like to
bring up the related topic of support for privacy-preserving updates of
transferable public keys (TPKs) in OpenPGP itself.

Summarizing the status quo: An OpenPGP TPK is structured as a primary key
packet, followed by a bunch of user id, subkey and signature packets. These
packets flexibly allow the primary key to bind semantics to itself, adding or
revoking signing and encryption keys, as well as self-stated designations
(particularly email addresses).

The composability of this data structure supports merging two versions of the
same TPK, which allows primary keys to update these semantics about themselves
by publishing new packets.

However, despite this flexibility, there are shortcomings for the use case of
distributing these updates in a privacy-preserving way:

1. A TPK must consist of a primary key, followed by at least one UserID.
Strictly speaking there doesn't have to be a signature on that User ID, but in
practice OpenPGP implementations commonly consider TPKs that carry no UserID (or
no signed UserID) as invalid.

2. The relationship between signatures and their subkeys or UserID packets is
implicit in the structure of the TPK: A signature always relates to the latest
preceding user id or subkey.

3. Some semantics that relate to the primary key itself are placed in the
signatures of UserID packets. Among others, this affects capability flags for
the primary key and possible expiry dates.

Each of these points impact the practicability of privacy-preserving TPK
updates. Specifically, it would be nice to:

A) Distribute updates to subkeys and the primary key (expiry, revocation, etc),
without revealing the key's UserIDs.

B) Distribute updates to UserIDs (expiry, revocation, etc) without revealing the
UserID itself.

C) Create, distribute, and use keys without attaching UserIDs or other
designation metadata at all

Some of these shortcomings can be addressed by changing behavior of
implementations, some of them could be addressed by cleverly reusing existing
mechanisms, and some require new mechanisms altogether. Some of that is partly
done in dkg's "abuse resistant keyserver" document, recently on this list.
However, conventions and "clever reuse" beside the spec increases the volume of
"de facto" standardization in implementations, and bloats the amount of implicit
knowledge required to achieve interoperability.

I would really like to see these consideration addressed in the spec somehow.
If we can't get that done (being only cautiously hopeful that we can), it would
still be useful to gather insight from folks on this list on how these
shortcomings could best be addressed by implementations in the futue.

I'll leave it at this outline of the problem domain in this mail, but will
follow up with thoughts on solutions soon.

 - V