Mailing List Archive

export-drop-uids
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.
Re: export-drop-uids [ In reply to ]
Hi!

For those not ware of it: You can put export and import options also
into the keyserver options, like

gpg --keyserver-options export-drop-uids --send-keys KEYIDS

The SKS keyservers don't fail on sending keys without a user id but it
is currently not possible to retrieve them. FWIW, I uploaded this key

pub rsa3072 2018-09-10 [SCEA]
8888840D56AB5E1574A8CEA5526C1080EC5EA42F
sub rsa3072 2018-09-10 [E]
sub rsa1024 2018-10-02 [S]



Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: export-drop-uids [ In reply to ]
On 10/4/18 12:43 PM, Werner Koch wrote:
> The SKS keyservers don't fail on sending keys without a user id but it
> is currently not possible to retrieve them. FWIW, I uploaded this key

It could actually be used with existing network if a
non-cryptographically correct UID was used as a placeholder, just with
<uid>nodata</uid> style ..

A bit time constrained atm but will look into things a bit more ahead of
the october meeting so that we have something more to discuss then.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Aurum est Potestas
Gold is power