Jacob Bachmeyer jcb62281 at
Tue May 2 04:43:57 CEST 2023

Michael Richardson wrote:
> Jacob Bachmeyer <jcb62281 at> wrote:
>     >> I'm unclear if this is a new feature (I think so), and if so what happens if
>     >> the sender hasn't upgraded yet?
>     >>
>     > My understanding:  ADKs are new and do not work without support on the
>     > sender's side.  The ADK is a request to also encrypt any message to the
>     > subkey to the ADK.  If the sender's software does not understand that
>     > request, it does not happen.  If the sender rejects that request, either
>     > by setting an option or by patching their software to ignore the request, it
>     > does not happen.
> Does it still (by default) encrypt to the main key?

My understanding:  Yes, if ADKs are not supported, the message is 
encrypted only for the main key.

> [...]
>     >> > 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.
>     >>
>     >> Yes, reasonable.
>     >> OTH, the emails investigating the insider trading by the HR people might need
>     >> to avoid the ADK.
>     > If we are talking about investigating HR malfeasance, those messages would
>     > not be going to the traders' regular inboxes in the first place.  You are
>     > right that an HR ADK could be a very bad idea in this example, since it could
>     > allow HR to front-run their own employer.  The expected solution would be to
>     > give the trading archives only to the audit or legal departments, and only
>     > after some period of time has passed.  That still leaves potential auditor or
>     > lawyer malfeasance, but that is an existing risk such businesses already
>     > handle.
> It's the initial investigation of an irregularity where there could be a problem.
> There is also an issue with 2FA and password reset emails: it's something
> that may be a vulnerability to archive.  Okay, few are encrypted today, but
> we can hope.   Many companies with forced proxis are starting to realize that
> they become liable when they store banking login cookies.

Really, the banks should be recognizing those networks and denying 
logins.  Perhaps corporate forced proxies should be required to insert 
an additional header reporting that the connection is not actually 
point-to-point encrypted, which banks and other sensitive services could 
use to reject sessions.

The main problem here seems to be a work-life balance issue.  People 
should not be conducting personal business on the company network, and, 
in turn, companies need to understand that personal time outside of work 
is /personal/ /time/ /outside/ /of/ /work/.  I am not sure in which 
direction this first broke down, but it is the root cause of a wide 
variety of problems.

> Anyway, I think senders need to be made mildly aware that it's occuring, and
> I think they should be allowed to pick a specific ADK or suppress them all in
> certain circumstances best decided by them.

I believe that is substantially what I proposed, so at least two of us 

-- Jacob

More information about the Gnupg-users mailing list