Subject: Re: [openpgp] Privacy-preserving Transferable Public Keys

From: Heiko Stamer <[email-masked]>
Date: Thu, 13 Jun 2019 23:59:22 +0200

On 31 May 2019 at 09:42, Vincent Breitmoser wrote:

> 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.

I'll change that in DKGPG soon, however, to avoid trouble IMHO some kind
of self-signature is still required (e.g. type 0x1f).

> I would really like to see these consideration addressed in the spec somehow.

Thus I suggest to change (in section 11.1 of draft RFC 4880bis)

    Zero or more revocation signatures

to

    Zero or more revocation or direct key signatures

to cover such use cases without user IDs or user attributes. Perhaps
already RFC 4880 had those scenarios in mind (cf. section 12.1):

    Primary-Key
      [Revocation Self Signature]
      [Direct Key Signature...]
      [User ID [Signature ...] ...]
      [User Attribute [Signature ...] ...]
      [[Subkey [Binding-Signature-Revocation]
              Primary-Key-Binding-Signature] ...]

--
Heiko

---

From: Werner Koch <[email-masked]>
Date: Fri, 14 Jun 2019 07:51:02 +0200

> of self-signature is still required (e.g. type 0x1f).

Right.  Most properties of an OpenPGP key are conveyed via
self-signatures.  Thus for general use they are really important.  Derek
has a very special use case and that is why the need for a
self-signature has been dropped.  Almost all other applications still
need them.

Direct key signatures can of course be used but we do not have much
experience with them.  I fear that some OpenPGP implementations will not
work correctly if only such a direct key self-signature is available.

Salam-Shalom,

   Werner

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

---

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 14 Jun 2019 09:22:21 +0200

> work correctly if only such a direct key self-signature is available.

Agreed, we can't change that very easily. But we can progress by allowing
partial TPKs during transit, see how implementations react, and build from
there.

 - V

---

From: Werner Koch <[email-masked]>
Date: Fri, 14 Jun 2019 10:36:57 +0200

On Fri, 31 May 2019 09:42, [email-masked] said:

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

Easy for new and revoked subkeys.

For full revocations gpg has always allowed to import a standalone
revocation self-signature.

For changing expiration or preferences the user id is required or the
client needs to trial verify all new self-signatures.  The server won't
be able to check the self-signatures if it has no access to the user-id.
This will spam the users and server with bogus self-signatures.

Right, direct key signatures can be used but I we have not much
experience with them.

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

This is the same as A modulo direct key signatures.

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

Why should one want to do that?  The user id (i.e. mail address or DNS
name) is important meta data.  However, it is better to use a direct
mapping from the user id to the key than any arbitrary mapping as done
by keyservers.  Then any updates to the user id can be retrieved via
that userid->keyblock service.

> done in dkg's "abuse resistant keyserver" document, recently on this list.

The simplest way to avoid DoS on keyservers is to disallowing searching
by user id.  That is for about 20 years standard at MTAs and although
not a perfect solution it has helped a lot against mail address
harvesting by asking MTAs.

Shalom-Salam,

   Werner

---

From: Vincent Breitmoser <[email-masked]>
Date: Sun, 16 Jun 2019 14:14:48 +0200

Hi Werner,

thanks for your response!

> Easy for new and revoked subkeys.

Easy how? You mean by allowing import of subkeys from TPKs without user ids? I'm
a bit confused here: in the patch series I submitted to GnuPG towards that
effect, said you weren't happy with this approach and referred to this thread.
Perhaps I misunderstood.

> Right, direct key signatures can be used but I we have not much

Agreed. There are a bunch of details that would have to be figured out for this
approach.

I hope we can agree though that the idea of per-userid preferences ("this user
id prefers Twofish, this other one AES") causes more problems and
inconsistencies than it is worth.

> name) is important meta data.

User IDs have value when a key wants to publicly claim a designation, and this
is necessary for WoT style workflows where people sign this binding.  But this
use case hasn't exactly stood the test of time.

With key discovery mechanisms like Autocrypt or WKD (the future!), we don't
really depend on user ids anymore.  Clients that have domain knowledge of the
context that keys are used in (e.g.  email clients) can assign much more useful
labels than openpgp implementations themselves.   This isn't just theory:
OpenKeychain and K-9 associate keys with email addresses from Autocrypt keys
independently from user ids, and can even work without user ids altogether.
Enigmail maintains a similar mapping, and it is a central part of the Autocrypt
spec.  Sequoia uses a "pet names" concept that works similarly.  I also think
this is basically what GnuPG does with its TOFU trust model, at least that's
what the database structure looks like.

All of that said, I don't want to push super hard towards getting rid of user
ids right now, or even at all.  Perhaps we never can get that far.  But thinking
about where we can reduce metadata that isn't strictly necessary is a good
thing, so yes I would welcome if we converged in a direction that reduced our
reliance on user ids a bit.

Moving from user ids to direct key signatures is probably too difficult in terms
of backwards compatibility. But "unstated user ids", as similarly suggested in
the abuse-resistant-keyserver draft, could be a good compatible step in this
direction.

 - V