Re: ADK's
Andrew Gallagher wrote: > The only way that a company would end up archiving a password reset > email encrypted to an ADK would be if an employee was using their work > email address for password resets. If using their work email for this > purpose is inadvisable, then it is inadvisable regardless of ADKs. Like you mean, an employee was using a work email for a work thing, maybe? > ADK introduces no new considerations that are not also an issue for key > escrow, which happens anyway, and has several advantages over escrow, I agree. > If you don’t trust your correspondent’s employer, then the only > effective course of action is to not use their employer’s email > address. Technical measures cannot protect you from opsec problems. I'm asking to be informed so that I can make the decision to do something else. 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 2 May 2023, at 02:18, Michael Richardson wrote: > > It's the initial investigation of an irregularity where there could be a > problem. These examples are becoming increasingly contrived. If you are investigating fraud by someone who can read all your company emails, don’t discuss it over company email. This is really basic stuff. > 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. Password reset emails are supposed to be immune to replay attacks. > Many companies with forced proxis are starting to realize that > they become liable when they store banking login cookies. The only way that a company would end up archiving a password reset email encrypted to an ADK would be if an employee was using their work email address for password resets. If using their work email for this purpose is inadvisable, then it is inadvisable regardless of ADKs. > 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. If I add an ADK notation to my key for legitimate reasons that I do not discuss with all my correspondents, on what basis do they decide to second guess it? How is this any different from where I store my private key, whether it is escrowed, whether it has a password etc, which are invisible to the sender and generally none of their business? If you don’t trust how I manage my key, the only reasonable recourse is to avoid using it. ADK introduces no new considerations that are not also an issue for key escrow, which happens anyway, and has several advantages over escrow, particularly transparency. If however it became common for people to disable encrypting to the ADK, it would simply encourage companies to stop using it and keep using escrow, which doesn’t prevent any of the proposed abuses. If you don’t trust your correspondent’s employer, then the only effective course of action is to not use their employer’s email address. Technical measures cannot protect you from opsec problems. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On Sun, 30 Apr 2023 13:58, Andrew Gallagher said: > The danger of an “ignore ADK” option is that it gives a false sense of And not to forget the other important use case: Add an ADK for your own second device so that you are able to decrypt also on that device - without the need to keep the pimary key on that device. BTW, OpenKeychain does something very similar for many years. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
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: 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
Re: ADK's
Michael Richardson wrote: Jacob Bachmeyer via Gnupg-users 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
Re: ADK's
Jacob Bachmeyer via Gnupg-users 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 I'm unclear if this is a new feature (I think so), and if so what happens if the sender hasn't upgraded yet? > 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. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
Johan Wevers via Gnupg-users wrote: On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote: [...] The danger of an “ignore ADK” option is that it gives a false sense of security. It is already possible for an employer to require escrow of the decryption subkeys of their employees - ADK actually makes this process more transparent. That might be, but it is nowhere certain that this escrow will happen, especially if they roll out adk's. Not providing such an option might be a case where the perfect is the enemy of the good: it might not be a perfect solution but it can be better than the alternative. Besides, this is begging for GnuPG forks to arise, and if those forks are well implemented remains to be seen. Maybe the best option here is an "--override-encryption-target KEYGRIP/SUBKEYGRIP" option, repeatable to encrypt to multiple specific subkeys of the same or different PGP keys, which is why it requires both a keygrip and a subkeygrip. This would also allow encrypting to some ADKs while ignoring others and resolve the demands for an "ignore ADK" option. 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. 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. -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
There are 2 simple workarounds to employment ADK's : [ 1 ]. Send a symmetrically encrypted message to the key with the ADK(This will require an agreed upon symmetric passphrase communicated in person, phone, or another non-ADK manner) [ 2 ]. Generate a non-ADK key, not uploaded to any server and send and receive messages with a hidden-ID option, and keep this key on a separated keyring. This can be communicated symmetrically as in [ 1 ]. vedaal___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
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? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ 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 05:41:31PM +0200, Johan Wevers 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? 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 2023-04-30 16:54, Andrew Gallagher via Gnupg-users wrote: >> That might be, but it is nowhere certain that this escrow will happen, >> especially if they roll out adk's. > > You’re inverting the burden of proof here. The important consideration is > that E2E can’t prove that a key *wasn’t* escrowed - so it’s much better for > the software to make no claims about it than potentially misleading ones. There is also no strict proof that the employer doesn't have access to the personal key of the receiver. All I want is an option to ignore adk's - and it should not claim anything else than that. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On 30 Apr 2023, at 14:42, Johan Wevers via Gnupg-users wrote: > > On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote: >> Whether this is done voluntarily or under duress from their employer is an >> opsec issue, not a comsec one. > > If it is an ex-employer that might be more compicated. Indeed. If this is in your threat model then don’t use work email addresses for personal communication, because encryption cannot protect you. >> The danger of an “ignore ADK” option is that it gives a false sense of >> security. It is already possible for an employer to require escrow of the >> decryption subkeys of their employees - ADK actually makes this process more >> transparent. > > That might be, but it is nowhere certain that this escrow will happen, > especially if they roll out adk's. You’re inverting the burden of proof here. The important consideration is that E2E can’t prove that a key *wasn’t* escrowed - so it’s much better for the software to make no claims about it than potentially misleading ones. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote: > E2E encryption can’t protect you from your correspondent disclosing your > communication at the other end. That is obvious. > Whether this is done voluntarily or under duress from their employer is an > opsec issue, not a comsec one. If it is an ex-employer that might be more compicated. > The danger of an “ignore ADK” option is that it gives a false sense of > security. It is already possible for an employer to require escrow of the > decryption subkeys of their employees - ADK actually makes this process more > transparent. That might be, but it is nowhere certain that this escrow will happen, especially if they roll out adk's. Not providing such an option might be a case where the perfect is the enemy of the good: it might not be a perfect solution but it can be better than the alternative. Besides, this is begging for GnuPG forks to arise, and if those forks are well implemented remains to be seen. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On 30 Apr 2023, at 13:45, Johan Wevers via Gnupg-users wrote: > > On 2023-04-30 14:10, Werner Koch via Gnupg-users wrote: > >> It does not make any sense so have such an option. If a user wants to >> allow colleagues or an archive system to decrypt her mails that is her >> decision. > > What I've had in practice in one company: you got a company key with a > personal key and an adk added. Nothing to want from my part there. If I > want to mail someone at such a company I may just want to ignore the adk. E2E encryption can’t protect you from your correspondent disclosing your communication at the other end. Whether this is done voluntarily or under duress from their employer is an opsec issue, not a comsec one. If you don’t want your correspondent’s employer reading your emails, don’t send messages to their work email address. The danger of an “ignore ADK” option is that it gives a false sense of security. It is already possible for an employer to require escrow of the decryption subkeys of their employees - ADK actually makes this process more transparent. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On 2023-04-30 14:10, Werner Koch via Gnupg-users wrote: > It does not make any sense so have such an option. If a user wants to > allow colleagues or an archive system to decrypt her mails that is her > decision. What I've had in practice in one company: you got a company key with a personal key and an adk added. Nothing to want from my part there. If I want to mail someone at such a company I may just want to ignore the adk. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's (was: [Announce] GnuPG 2.4.1 released)
On 2023-04-30 13:22, Andrew Gallagher via Gnupg-users wrote: > Just curious, what’s the threat scenario here? The HR department of the receiver. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's
On Fri, 28 Apr 2023 16:57, Johan Wevers said: > So you finally caved in to the backdoor demands. In business it is quite common to share subkeys with others. Thus the ADSK makes it only more explicit and flexible. See the blog entry. > What I'm missing (maybe I just didn't found it?) is an option in my > config file to ignore adk requests and just don't encrypt to those keys It does not make any sense so have such an option. If a user wants to allow colleagues or an archive system to decrypt her mails that is her decision. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's (was: [Announce] GnuPG 2.4.1 released)
On 30 Apr 2023, at 11:30, Johan Wevers via Gnupg-users wrote: > > On 2023-04-30 1:15, ckeader via Gnupg-users wrote: > >> Can't call it that as long as it's under user control (every long option of >> the software has an equivalent config file option. You don't add such a key >> via config or command line, no adsk will happen as it's not configured). > > On my key, yes, I can choose to add an adk or not of course. But suppose > I want to encrypt to a key that has an adk added, but I only want to > encrypt to that key and not to the added adk? How do I do that? Just curious, what’s the threat scenario here? If you suspect that your correspondent’s key preferences have been tampered with by a third party then surely the entire key is supect and shouldn’t be used at all? If on the other hand you believe that it has not been tampered with, but your correspondent has been negligent in configuring it, then maybe you shouldn’t trust your correspondent? A signature.asc Description: Message signed with OpenPGP ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's (was: [Announce] GnuPG 2.4.1 released)
On 2023-04-30 1:15, ckeader via Gnupg-users wrote: > Can't call it that as long as it's under user control (every long option of > the software has an equivalent config file option. You don't add such a key > via config or command line, no adsk will happen as it's not configured). On my key, yes, I can choose to add an adk or not of course. But suppose I want to encrypt to a key that has an adk added, but I only want to encrypt to that key and not to the added adk? How do I do that? > If you're using gpg built by your org, you have no trustworthy environment > anyway. Probably, but when I answer a mail from home with my own GnuPG I want to be able to ignore adk's. > And the feature needs to be supported by the client. You, currently I run gpg 2.2 so it's not of immediate concern. But when I eventually upgrade I want to be able to ignore adk's. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's (was: [Announce] GnuPG 2.4.1 released)
Johan Wevers via Gnupg-users writes: > On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote: > > > * gpg: New command --quick-add-adsk and other ADSK features. > > [T6395, https://gnupg.org/blog/20230321-adsk.html] > > So you finally caved in to the backdoor demands. > > What I'm missing (maybe I just didn't found it?) is an option in my > config file to ignore adk requests and just don't encrypt to those keys > as well when I send or reply a message. Can't call it that as long as it's under user control (every long option of the software has an equivalent config file option. You don't add such a key via config or command line, no adsk will happen as it's not configured). If you're using gpg built by your org, you have no trustworthy environment anyway. And the feature needs to be supported by the client. In the face of email having been hijacked by the corporates/Micros~t+Exchange and intrinsically broken S/MIME, practical relevance: close to zero. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's (was: [Announce] GnuPG 2.4.1 released)
gnupg-users@gnupg.org wrote in <20230428230349.429d3d3a@localhost>: |Johan Wevers via Gnupg-users wrote: |>On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote: |> |>> * gpg: New command --quick-add-adsk and other ADSK features. |>> [T6395, https://gnupg.org/blog/20230321-adsk.html] |> |>So you finally caved in to the backdoor demands. | |If there is no option as you say, i would say yes. | |>What I'm missing (maybe I just didn't found it?) is an option in my |>config file to ignore adk requests and just don't encrypt to those keys |>as well when I send or reply a message. | |ACK, absolutely necessary. Otherwise GnuPG would no longer be a |trustworthy encryption solution. And Patrice Lumumba was thrown into a pit of slaked lime. (After being beaten to death with rifle butts on the flight from western to eastern Kongo, as far as i know. But wild times still under colonial money mighty. (Afaik.)) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) |~~ |..and in spring, hear David Leonard sing.. | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure |~~ |Farewell, dear collar bear ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ADK's (was: [Announce] GnuPG 2.4.1 released)
Hi Johan, Johan Wevers via Gnupg-users wrote: >On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote: > >> * gpg: New command --quick-add-adsk and other ADSK features. >> [T6395, https://gnupg.org/blog/20230321-adsk.html] > >So you finally caved in to the backdoor demands. If there is no option as you say, i would say yes. >What I'm missing (maybe I just didn't found it?) is an option in my >config file to ignore adk requests and just don't encrypt to those keys >as well when I send or reply a message. ACK, absolutely necessary. Otherwise GnuPG would no longer be a trustworthy encryption solution. -- mlnl GPG:1FC05426F87FA623 ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
