[PATCH GnuPG 2/2] gpg: allow import of previously known keys, even without UIDs

Mon May 13 18:19:20 CEST 2019

Thanks for this series, Vincent!  I like the motivation behind it.  I
think it is concretely useful to import an OpenPGP certificate as part
of a merge even if the incoming cert does not have a
cryptographically-valid self-sig over any user ID.

This permits the use of public keystores that perform the "redacting
User IDs" mitigation described at
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-5.1

In particular, it allows gpg to perform "Certificate Update with
Redacted User IDs":
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-5.1.1

(other operations later in section 5.1 that might involve synthesizing
user IDs are not yet supported, even with this patch, and that's ok)

It would be great to add a test to the test suite for this behavior --
to show what does *not* work before the patch is applied, and then to
have the test suite succeed after the patches are applied.  This would
also help us avoid regressions on this behavior in the future.

For example, here is a severely stripped down OpenPGP certificate.  Just
a primary key and one user ID and a self-sig:

Here is a cert for the same primary key, but with a subkey and no user
ID attached:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [B] primary key, subkey, subkey binding sig (no user ID)

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN24OARc2ZQhEgorBgEEAZdVAQUBAQdABsd5ha0AWXdXcSmfeiWIfrNcGqQK
j++lwwWDAOlkVicDAQgHiHgEGBYIACAWIQS0aY+VvNh/4EjMyikIQ9qWmqja+wUC
XNmUIQIbDAAKCRAIQ9qWmqja++vFAP98G1L+1/rWTGbsnxOAV2RocBYIroAvsbkR
Ly6FdP8YNwEA7jOgT05CoKIe37MstpOz23mM80AK369Ca3JMmKKCQgg=
=xuDu
-----END PGP PUBLIC KEY BLOCK-----

And here is a cert for the same primary key, with the user ID packet
stripped entirely, but with updated self-sig (issued after the initial
one) that contains a later expiration date over that same user ID:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: [C] primary key and self-sig expiring in 2024 (no user ID)

mDMEXNmUGRYJKwYBBAHaRw8BAQdA75R8VlchvmEd2Iz/8l07RoKUaUPDB71Ao1zZ
631VAN2IlgQTFggAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBLRpj5W8
2H/gSMzKKQhD2paaqNr7BQJc2ZR1BQkJZgHcAAoJEAhD2paaqNr79soA/0lWkUsu
3NLwgbni6EzJxnTzgeNMpljqNpipHAwfix9hAP93AVtFdC8g7hdUZxawobl9lnSN
9ohXOEBWvdJgVv2YAg==
=KWIK
-----END PGP PUBLIC KEY BLOCK-----

If i do "gpg --import" on A, then B, then C, and then i do "gpg
--edit-key test clean save" and "gpg --list-keys", i think gpg display
have a merged certificate that expires in 2024, and has a subkey, like
this:

    pub   ed25519 2019-05-13 [SC] [expires: 2024-05-11]
          B4698F95BCD87FE048CCCA290843DA969AA8DAFB
    uid           [ unknown] test key
    sub   cv25519 2019-05-13 [E]

but in practice, the imports of both B and C fail with:

    gpg: key 0843DA969AA8DAFB: no user ID

and the result is instead the same as if only A were present:

    pub   ed25519 2019-05-13 [SC] [expires: 2021-05-12]
          B4698F95BCD87FE048CCCA290843DA969AA8DAFB
    uid           [ unknown] test key

Feel free to use these example objects in the test suite if that's
useful.

On Sun 2019-05-12 12:36:56 +0200, Vincent Breitmoser wrote:
> * g10/import.c (import_one): Allow import of keys that have no user ids,
> if we already know them.  Keys are still rejected if they contained
> invalid user ids, or none that pass a given filter criteria.

Your commit message here doesn't seem to match the intent of this patch,
for several reasons:

 * It talks about several different keys, but it would be good to
   clarify in each circumstance whether we're talking about:

   a) the known copy of the OpenPGP certificate,
   b) the incoming copy of the OpenPGP certificate, or
   c) the merged copy of the OpenPGP certificate.

 * "contained invalid user ids" is different from "contained no valid
   user IDs"

 * "validity" for user IDs in the OpenPGP typically means something
   subtly different from "has a cryptographically correct self-sig from
   the primary key". It would be good to avoid mixing those up.

As a nit-pick, i'd also convert the description to refer to the
certificate in the singular instead of plural where possible, because
it's easier to read and make sense of (esp. when the cert itself might
have multiple elements internally).

rewriting to what i *think* the intent of the series is, i'd have
written it this way:

* g10/import.c (import_one): Accept an incoming OpenPGP certificate that
has no user id, as long as we already have a local variant of the cert
that matches the primary key.  Import still fails if the resulting
merged certificate contains no self-signed user ids that pass any given
filter criteria.

Is this your intent?

   --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-devel/attachments/20190513/46e699b6/attachment-0001.sig>