Should you include your email address on key server?

[Andrew Gallagher]

On 13 May 2025, at 13:13, Werner Koch via Gnupg-users <gnupg-users at gnupg.org> wrote:

> Keyserver can only be useful for distributing revocation certificates
> but in many cases this can also be done by the Web Key Directory (in
> fact gpg-wks-client appends revocations of old keys to new keys).

Note however that many clients cannot import the revocations as generated by gpg-wks-client. Because it appends detached signature packets to valid TPKs, these appear to be revocation signatures over the preceding primary key - but in most cases the last signable component of a TPK is a subkey, meaning that these primary key revocation sigs form an invalid packet sequence and so are often discarded on import. This is why hockeypuck always _pre_pends detached revocation packets, although it’s not clear whether all clients cleanly import those either… If gnupg would just implement T6900 this problem would go away of course. :-P

> Thus I
> consider to propose a new key flag to mark a subkey for use with chat
> program in contrast to mail/data use.

It might be more useful to define a generic domain separation scheme whereby a subkey could be tied to one or more applications (as represented by mime types or domains). This would avoid having to maintain a centrally-approved list of categories. Also remember we already struggle to make a clear distinction between the existing two categories of encryption usage. Does DeltaChat count as “email” or “chat”?

> This would allow to use the same
> key for mail and chat without risking to put the more valuable mail
> encryption key on a easier to attack smartphone.

Smartphones are pretty robust these days. I’d sooner trust an iphone to keep my secret key safe than Windows 11, for example. Since most normal people want to be able to read email on their phones, the main issue for them is how to get the secret key material onto the phone without using a transport mechanism that’s less secure than the devices on either end.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250513/91b7c6f9/attachment.sig>