4 ms·
You can do almost all of this within existing standards. The PGP identity token (AKA public key fingerprint) would be used as the primary email identifier. The
by upofadown 7y ago
You can do almost all of this within existing standards. The PGP identity token (AKA public key fingerprint) would be used as the primary email identifier. The embedded email address would then just be considered a technical routing detail. If you physically meet someone and want to "know" them in an email sense you just scan the QR code of their identity token (there is a standard for this too). When you decide not to know them anymore you just remove their identity. Knowing someone who knows you is a standardized process and technically is just an attachment of a PGP identity (public key). Knowing someone from their internet presence is also a standardized process.
This would be reasonably intuitive just as long as we were willing to give things sane names (e.g. Identity vs public key) and mail clients show clear statuses. We get encryption and identity reputation for free and can use it against spam as desired.
Those that do not know PGP are doomed to reinvent it...
- pcr910303 7y agoPlease don’t use PGP. Quoting ‘The PGP Problem’[0]: > PGP begs users to keep a practically-forever root key tied to their identity. It does this by making keys annoying to generate and exchange, by encouraging “key signing parties”, and by creating a “web of trust” where keys depend on other keys. > Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key. > The PGP cheering section will immediately reply “that’s why you keep keys on a Yubikey”. To a decent first approximation, nobody in the whole world uses the expensive Yubikeys that do this, and you can’t imagine a future in which that changes (we can barely get U2F rolled out, and those keys are disposable). We can’t accept bad cryptosystems just to make Unix nerds feel better about their toys. [0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
- riedel 7y agoThe GP only said you should know it not the reinvent it. The rant you are quoting does not add too much to that point IMHO (age, what the author suggest does not solve many problems) So what do you use for signing and encryption today when setting up a heterogeneous system like email or git?
- pcr910303 7y ago> So what do you use for signing and encryption today when setting up a heterogeneous system like email or git? I don't. For Email, quoting the aforementioned post[0]... > Encrypting Email > Don’t. > Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext. > This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending? > Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety. For signing commits in git, I'll quote Filippo[1]'s 'Sigining git commits considered harmful'[2] rant on Twitter. > One of my issues with it is that it's marketed for a problem it does not solve (git metadata authentication and identity) and it's way suboptimal for the problem it solves (signed releases). > I don't believe it works for that. You need at least a rebase (and key rotation, and identity) story for that. > Pushes can be just as important as contents (imagine force pushing an old signed vulnerable tree to master) and are completely unprotected by this model. > In the security space I struggle to see the line between "doesn't do the job" and "harmful", but sure, I am willing to downgrade "considered harmful" to "doesn't make sense". If you still want to encrypt something plain text though, I would recommend age[3], which is: > A simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability. [0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#encrypting-email https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#... [1]: https://filippo.io https://filippo.io [2]: https://twitter.com/filosottile/status/1248110291751231488 https://twitter.com/filosottile/status/1248110291751231488 [3]: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
- deleted 7y ago[deleted]
- upofadown 7y ago>... by encouraging “key signing parties”, and by creating a “web of trust” where keys depend on other keys. Welcome to the 90s. Does anyone actually ever do this sort of thing? Now you just aim your phone at a QR code on another phones screen. Times have changed... > Long term keys are almost never what you want. Long term keys represent long term identities. So, yes, you do want that. PGP has subkeys that you can revoke whenever you want thus preserving your identity. I can't think of of any other system that supports this in such a straightforward way. Your phone gets owned and you basically lose everything. If you keep your master PGP key on a more secure device you are still in business...
- m-p-3 7y agoExactly, the best practices with PGP is to generate a main key for long term use and kept in cold storage, and generate subkeys that will be used on specific devices and revoked whenever necessary. The idea of a root of trust can be applied here as well.