OAuth2 relies on HTTPS and thus the Web PKI to prevent anyone from MitMing either the login page itself or API requests made using the OAuth token. SSH's trust

OAuth2 relies on HTTPS and thus the Web PKI to prevent anyone from MitMing either the login page itself or API requests made using the OAuth token. SSH's trust-on-first-use system is only secure under the assumption that you "usually" aren't being MitMed; this ought to be improved. For the typical server administration use case, I'd prefer a design that doesn't involve PKI – like encoding a hash of the key into the SSH command – but domain validation based on Web PKI could still be better than nothing. (Perhaps using some subdomain owned by the hosting provider, as opposed to the public-facing domain(s) for the server.) Domain validation would also be ideal for use cases where you're connecting not to your own server but to some known entity's, such as SSHing to GitHub. As for SSH CAs... I've never heard of them before. :) Looking it up, I see that some organizations use them, but I'm not sure their design is a good fit for the kind of non-organization-internal use cases I'm thinking of. As it stands today, Signal's public key system is largely security theater since nobody bothers to check authentication codes. Even when people do check them, you always have an excuse for changing your code out of the blue (got a new phone, had to reset my phone, etc.), which an attacker can take advantage of. The latter could be fixed by having a better way to transfer trust between devices, but Signal could still have a better story for initial authentication than trusting the phone system. Now, I don't think a traditional PKI would help. But I do like what Keybase is doing here, bootstrapping trust off of a collection of signed attestations on social media accounts. I'd argue this amounts to a PKI in its own right, one where social media providers (unknowingly) play the role of CAs.