ADK's

[Jacob Bachmeyer]

Johan Wevers via Gnupg-users wrote:
> On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:
>
> [...]
>   
>> The danger of an “ignore ADK” option is that it gives a false sense of security. It is already possible for an employer to require escrow of the decryption subkeys of their employees - ADK actually makes this process more transparent.
>>     
>
> That might be, but it is nowhere certain that this escrow will happen,
> especially if they roll out adk's. Not providing such an option might be
> a case where the perfect is the enemy of the good: it might not be a
> perfect solution but it can be better than the alternative.
>
> Besides, this is begging for GnuPG forks to arise, and if those forks
> are well implemented remains to be seen.

Maybe the best option here is an "--override-encryption-target 
KEYGRIP/SUBKEYGRIP" option, repeatable to encrypt to multiple specific 
subkeys of the same or different PGP keys, which is why it requires both 
a keygrip and a subkeygrip.  This would also allow encrypting to some 
ADKs while ignoring others and resolve the demands for an "ignore ADK" 
option.

ADKs seem particularly valuable to me as a solution to the "group inbox" 
problem that avoids actually sharing private key material:  simply 
attach encryption subkeys for all recipients to the "group inbox" 
certificate.  This requires publishing new certificates when the 
recipient list changes and discloses the recipient list to some extent, 
but that is the trade-off for end-to-end security in this context.  
Could a "--notify-ADK-encrypt" option that could be placed in the 
configuration file be appropriate to address user concerns about 
possible improper proliferation of ADKs?  Should a notification that an 
ADK was used actually be default?  After all, there are legitimate uses 
for ADKs, but an ADK turning up where not expected could be a strong 
hint that you have a bogus certificate.

I would also note that, for a work email system in an environment where 
there is a legal or quasi-legal requirement (not uncommon in finance) to 
archive messages, simply dropping any incoming message not decryptable 
with the archive ADK as spam would be reasonable.  Since the primary 
concern motivating message archival in this example is deterring insider 
trading, simply not allowing unreadable messages to be delivered 
accomplishes the same objective.


-- Jacob