allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information

[Daniel Kahn Gillmor]

On Thu 2019-08-01 13:37:26 +0200, Werner Koch wrote:
> The user ID is important because the accompanying self-signature conveys
> important information about the keyblock.  For example expiration date
> and preferences.  It is true that this can also be conveyed with
> direct-key-signatures (a self-signature directly on a key which was
> mainly introduced for dedicated revocations).  However, this is a not so
> well tested feature of gpg and my educated guess is that many other
> OpenPGP implementations do not handle direct-key signatures in a way
> compatible to pgp or gpg - if at all.  Thus by relying on them we would
> sail into uncharted waters.

We're already in uncharted waters with the inevitable abuse of SKS, we
need to figure out how to stabilize the ecosystem.

>> Doing such a merge would be super helpful, particularly for receiving
>> things like subkey updates and revocation information from
>
> I agree that we can add a code path to import a primary key plus
> revocation certificate but without user-ids.  PGP however, does not
> support this and is the reason why we extended the revocation
> certifciate with a minmal primary key.

If the PGP implementation of OpenPGP has bugs or doesn't behave well in
the context of a minimized/stripped certificate, let's ask them to fix
those bugs.  The bugs in how that implementation interprets data are
irrelevant to data that 

> Update of subkeys is a different issue and I see no solid use case for
> allowing that without user-id (cf. expiration date of the primary key).

Here's one use case (i've got others if you want):

 * You have my OpenPGP certificate (with userid with e-mail address),
   but it is not published in full publicly because i do not want people
   to be able to find anything related to my e-mail address online.

 * It has an encryption-capable subkey "X" that expires in 1 year, which
   i use to be able to have deletable messages.  I will destroy the
   secret component when X expires.

 * As the year draws to a close, i create a new subkey "Y" and i attach
   it to my OpenPGP certificate, and i push the updated certificate to
   an abuse-resistant keystore (like keys.openpgp.org), again declining
   to allow it to publish my e-mail address.

 * After the expiration of "X", you want to send me an encrypted mail
   (as is your habit when mailing me).  You follow best practices and
   refresh your keyring (fetching certificate updates by primary key
   fingerprint) from a public, abuse-resistant keystore.  Does your
   OpenPGP implementation learn about "Y" when it pulls in the update?
   It should.

If it does not, you will end up sending me cleartext e-mail,
pointlessly, because your local client had the opportunity to know (for
certain -- with cryptographically-verifiable evidence!) that a
non-expired encryption-capable subkey was available, associated with the
given primary key.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190801/12e25b01/attachment.sig>