The idea here is applicable to end to end encrypted messaging in general. Basically the identity information for a user specifies more than one encryption key in a secure way. Someone sending a message to that user then knows that the user wants the message encrypted for all the given encryption keys.
The idea here is to make end to end encryption more acceptable to companies with compliance or legal obligations to archive messages. It is generally applicable to any situation where the employee is unavailable to decrypt their messages where that is a problem.
The second encryption key of an employee would be the archive identity. The archive identity would be controlled by a trusted person or persons who would only have to dig into the archive if there was an actual issue. Otherwise the archive could be left secure.
this was rejected once. called big brother key in the lists if you wanna search for context and educate yourself better.
argument was this workflow is already possible. just encrypt an archive version as needed.
the original proposal asked for a always on key and was implemented with no user feedback. heh.
this uses a subkey on the original to key. less bad but still bad.
if more than one person must sign/decrypt, they should share the ownership of the private keys. you can already do these hacks where two private keys can unlock the secret to a third key etc. plenty of solutions.
this will just be used as a way to get a backdoor by offering less resistance on a corp environment. remeber, control comes not from forcing you to do something, but making you not care.
>this was rejected once. called big brother key in the lists if you wanna search for context and educate yourself better.
I found that the summary and the link at the end of the linked article was good enough. My understanding was that there was an actual bug in the implementation that caused a security weakness.
The idea here is to make end to end encryption more acceptable to companies with compliance or legal obligations to archive messages. It is generally applicable to any situation where the employee is unavailable to decrypt their messages where that is a problem.
The second encryption key of an employee would be the archive identity. The archive identity would be controlled by a trusted person or persons who would only have to dig into the archive if there was an actual issue. Otherwise the archive could be left secure.