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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
