If you’re trusting a party for identity verification of a party you’re communicating with, isn’t that implying trust with the correspondence itself? After all, they could just “verify” themselves as the other party of your correspondence.
It’s the same principle as user permission management—if someone has the ability to grant permissions then they are a superuser, because they can grant any additional permission to themselves.
Just because I trust you to recommend a therapist doesn't mean I'll trust you to listen to my therapy session and keep it private. Or that you wouldn't try to decode messages.
I believe that you are supposed to use identity providers that aren't involved in the actual transmission of the message.
For example suppose I want to send you an encrypted message. Your email address is in your HN profile. I ask an identity provider for a public key for that email address, encrypt my message using that key, and send it to that email address.
Identity provider shenanigans might result in me encrypting that message with a public key whose private key might be known by the identity provider or other third parties, but unless they can intercept my mail in transit or gain access to it in your mailbox they can't make much use of that.
> After all, they could just “verify” themselves as the other party of your correspondence.
They can't do this at any real scale, because they will be caught. (Because they can't use the same key as the real key--since they don't have the private portion, if designed sanely--so anyone verifying it manually out of band will see that the trust has been violated. Also they will have to continuously modify future communications, which can be difficult, which is another way to get caught.)
If that was possible, we wouldn't need Certificate Transparency (whose purpose is to at scale detect Certificate Authorities doing this and other shenanigans).
Also "being able to catch them" is strictly better than "basically not able to catch them", which is the case for Twitter DMs (and most common DM systems), which was mentioned up-thread.
Why/how would they get caught in the identity-based scheme mentioned in the article? What are you even verifying out of band in this context?
Like all that you wrote is true of webPKI that we use on the internet for TLS, but the article is talking about an alternative that is not PKI, and does not work the same way.
It’s the same principle as user permission management—if someone has the ability to grant permissions then they are a superuser, because they can grant any additional permission to themselves.