On 5 May 2023, at 17:55, Ineiev wrote:
>
> On Thu, May 04, 2023 at 11:01:36AM +0100, Andrew Gallagher wrote:
>>> I tried something like this with my MUA, I believe that doesn't work:
>>> it first looks for appropriate keys, probably using --list-keys;
>>> in fact, it insists on choosing a single
On Thu, May 04, 2023 at 11:01:36AM +0100, Andrew Gallagher wrote:
> > I tried something like this with my MUA, I believe that doesn't work:
> > it first looks for appropriate keys, probably using --list-keys;
> > in fact, it insists on choosing a single key when multiple ones
> > are available.
>
On Thu, 4 May 2023 09:43, Ineiev said:
> This is another issue ADK might handle differently---if gpg skipped
> validation of the donor keys (where ADK subkeys come from),
The ADSK shall work very similar to --encrypt-to - that is it is only
used if there is already an encryption key. That is
On 4 May 2023, at 10:43, Ineiev wrote:
>
> On Thu, May 04, 2023 at 09:52:54AM +0100, Andrew Gallagher wrote:
>>
>> andrewg@serenity % gpg --group
>> fn...@test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A -r fn...@test.eu -e <
>> /etc/shells > shells.gpg
>> gpg: 0x40F9B9601900E974: There is no
On Thu, May 04, 2023 at 09:52:54AM +0100, Andrew Gallagher wrote:
> > $ gpg --group fn...@test.eu=BD9D4DEE7B2FF1CBEF2EE0C4E0ACD3E0CBE7874A
> > --list-keys fn...@test.eu
> > gpg: error reading key: No public key
...
> —list-keys doesn’t expand groups. Try this instead:
>
>
> andrewg@serenity %
On 4 May 2023, at 06:46, Ineiev wrote:
>
> On Mon, May 01, 2023 at 03:16:12PM +0100, Andrew Gallagher wrote:
>> 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
On Mon, May 01, 2023 at 03:16:12PM +0100, Andrew Gallagher wrote:
> 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
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
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
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
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
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
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
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
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?
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"
>
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
- 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
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
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 ht
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
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 pro
le 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 burde
kes 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 t
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.
>
>
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
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
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
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
yway.
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
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
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]
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
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
34 matches
Mail list logo
