Re: ADK's
Michael Richardson wrote: Jacob Bachmeyer 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 agree. -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
Jacob Bachmeyer 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 [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Announce] GnuPG 2.4.1 released
Werner Koch via Gnupg-users wrote: > On Fri, 28 Apr 2023 11:21, Todd Zullinger said: > >> It seems neither of these files have not made it to the >> server yet: > > Sorry for that. I have used a new build machine and obviously forgot > one of the last steps. Most of the release process is scripted but the > final upload needs to be done manually (after signing, copying to the > internal archive, updating the repo, writing announcement and updating > the web page). > > Fixed after Bernhard called me at home. Sorry it interrupted your weekend. Thanks for the new release and all of your work on GnuPG and OpenPGP. :) -- Todd signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On 1 May 2023, at 12:40, Ineiev via Gnupg-users wrote: > now, I generate a key > for y...@guan.edu locally and add 0123456789ABCDEF as an ADK (BTW, > will GnuPG complain if the only encryption-capable subkey is ADK? Or you could just use an alias…? A ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On Sun, Apr 30, 2023 at 10:52:10PM -0500, Jacob Bachmeyer via Gnupg-users wrote: > > 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. It looks like the feature will allow for quite unexpected (if not unintended) uses. Another potential use is: I have reasons to believe that the holder of the key 0123456789ABCDEF controls the email y...@guan.edu, but that key has no user ID with such email, and I couldn't validate any other emails in that key. when I'm writing to that email, my MUA will look for keys with user IDs that match it. now, I generate a key for y...@guan.edu locally and add 0123456789ABCDEF as an ADK (BTW, will GnuPG complain if the only encryption-capable subkey is ADK? can I make all self-signatures local in order to avoid sending the key to keyservers?) signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
Hi Johan,
Johan Wevers via Gnupg-users wrote:
>On 2023-04-30 21:01, Ineiev via Gnupg-users wrote:
>
>>> All I want is an option to ignore adk's - and it should not claim
>>> anything else than that.
>>
>> Can't you remove ADK subkeys from your keyring?
>
>On someone else's key?
>
Yes.
1. identify ADK key: [R]/usage: R ("restricted encryption key") and
extract adk's fingerprint
2. gpg --batch --delete-keys adkfp!
after every key import or refresh.
--
mlnl
GPG:1FC05426F87FA623
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
