ADK's

[Ineiev]

On Sun, Apr 30, 2023 at 10:52:10PM -0500, Jacob Bachmeyer via Gnupg-users wrote:
> 
> That is an almost prototypical example.  In that case, the "archive" key
> would actually be the main subkey, and the list recipients' personal keys
> would be attached as ADKs.
> 
> Another example:  suppose I have multiple hardware tokens and wish to be
> able to use them interchangeably, but also want maximal security with this
> arrangement, so have generated an encryption keypair on each token.  I list
> all of the per-token subkeys as ADKs.  In this case, the ADKs really would
> all be /my/ keys.  Again, I would have to publish a new certificate every
> time my collection of live tokens changes, which may or may not leak useful
> information to an adversary.

It looks like the feature will allow for quite unexpected (if not
unintended) uses.

Another potential use is: I have reasons to believe that the holder
of the key 0123456789ABCDEF controls the email yu at guan.edu, but that
key has no user ID with such email, and I couldn't validate any other
emails in that key. when I'm writing to that email, my MUA will look
for keys with user IDs that match it. now, I generate a key
for yu at guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
will GnuPG complain if the only encryption-capable subkey is ADK?
can I make all self-signatures local in order to avoid sending
the key to keyservers?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230501/443eea89/attachment.sig>