Michael Richardson wrote:
Jacob Bachmeyer via Gnupg-users <gnupg-users@gnupg.org> wrote:
> 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.
That would be really useful for secur...@example.com
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.
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.
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 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.
-- Jacob
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
