ADK's

[Michael Richardson]

Jacob Bachmeyer <jcb62281 at gmail.com> 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 primary reason for arguing to support some way to suppress the use of an
    > ADK when encrypting is that, as Johan noted, this is an issue where feelings
    > are strong enough to provoke forks, which are likely to simply rip out ADK
    > support entirely, thus making its legitimate uses (group inboxes, multiple
    > tokens, business-related) unreliable.

I agree with this view.

    >> > 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.

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 511 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230501/a1f57a86/attachment-0001.sig>