export-drop-uids

[Werner Koch]

Hi!

Recent problems with the keyserver network may require that we rethink
how we can use the keyservers in another way.  To help evaluating such other
ways I added two utility features to gpg in master:

--export-options has the new sub-option:

     export-drop-uids
              Do no export any user id or attribute  packets  or  their
              associates signatures.  Note that due to missing user ids
              the resulting output is not strictly RFC-4880 compliant.

and --import-options has the new sub-option:

     import-drop-uids
              Do  not  import any user ids or their binding signatures.
              This option can be used to update  only  the  subkeys  or
              other non-user id related information.

One idea is to use the new export option to send keys stripped of all
user ids and their self- and key-signatures. to the servers.  The
servers would then not anymore carry mail addresses or other personal
information [1], However it should still be possible to query the
keyservers for revocation certificates and new subkeys.  User-ids will
be kept away from them as well as key-signatures.  The complete key
including the user ids and maybe key-signatures can still be queried by
other means (e.g. Web Key Directory).

When creating a new key the user could upload the entire key to the Web
Key Directory and use the new export option to upload the key sans user
ids to the keyservers.

Sending encrypted mail will work because the peer's key can be
looked up by mail address in the mail provider's directory.

Checking for revocations works by uploading a revocation to the
keyservers and due to regular checking the keyservers for updates.

Subkey rollover works by uploading the updated key to the keyserver
(sans user id).

Verifying signatures can be made to work because the key can be looked
up by fingerprint from the keyservers.  However, it does not identify
the user - this can however be done on user demand by looking up the
original key via the From address at the Web Key Directory.

The new import option would be useful to avoid importing unwanted
key-signatures from a keyserver,

If such a scheme turns out to be useful these options can be added to
the keyserver related commands.  Problems right now are that gpg will
reject encrypting to a key without a user-id, even so that the key has
been imported. I have not yet tested whether the keyservers are able to
handle keys without user-ids.  We also need to create direct key
signatures to convey properties of the key even without user ids.  And
well, --search-keys will not be useful anymore because keyservers won't
carry user ids anymore.

A slightly different approach would be to use dummy user ids and a
non-keyserver-uploaded mapping of these dummy-user id to the real user
ids.  This has the problem of complexity and that it will be easy to
test whether a certain user id can be mapped to such a dummy user id and
a key.


Salam-Shalom,

   Werner


[1] According to some interpretation of data protection rules.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181002/0871ec32/attachment.sig>