On 2 May 2023, at 02:18, Michael Richardson <m...@sandelman.ca> 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
