ADK's

[Jacob Bachmeyer]

Michael Richardson wrote:
> Jacob Bachmeyer via Gnupg-users <gnupg-users at 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 security at 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