If confidentiality is required, well you already have a public key that you're using to verify content, then the content can say: "reach us at 196.7.3.45" and then you encrypt communications to that address with the same public key you use for validating content.
Or maybe they'll specify, in the content, that you should use a different key for that, but either way the chain of trust is preserved.
This would of course all be protocol level stuff, handled by the browser, not a human. They just have to maintain a list of keys they trust.
Um, I don't think you understand this problem near as good as you think you do?
>A man in the middle can pass the content along or they can refuse to do so but they can't forge a signature.
So where do you get this signature exactly so they don't MITM you the first time?
> well you already have a public key that you're using to verify content,
Who what where when why? Where did I get this public key? Who provided it? Is this my public key or their public key? How do I trust it?
>They just have to maintain a list of keys they trust.
So you've solved exactly nothing.
That's always going to depend on why you're trusting them in the first place. If somebody handed you a business card the key should be on the card. If it was a recommendation from a friend you should use whatever key they use.
If you're expecting to just type random IP addresses into your browser until you hit something and then be told that you should trust what you see... Well that's not in the cards because you shouldn't trust what you see in that scenario.
We already don't type in URL's, we send links to each other. It really wouldn't be so difficult to change the UX so that when we delegate trust in that way it's public keys that are being trafficked instead.
> So you've solved exactly nothing.
Removing untrustworthy third parties and the need to revoke trust in them on the user's behalf is the solution. Users don't know what a CA is or how they should evaluate its trustworthiness. We need a system where they're instead evaluating the trustworthiness of things they understand, like other people.
When they get burned they should have the ability to immediately revoke trust in whoever burned them. This thing we're doing where we expect them to wait around while some nerd pushes the updated list to them and to blindly trust that that nerd isn't curating that list with ulterior motives is totally bonkers.
RFC 7469 appears to be more geared towards service providers attempting to protect their users. Laudable, but we're still assuming we know something about who the user deems trustworthy, which I think is presumptuous.
It's one thing to suss out cases where somebody is lying about their name, that's pretty cut and dry. But ever since web2.0 there's no longer much of an association between the hostname and the trustworthiness of the content. If we instead provided a means of validating the content's provenance it wouldn't much matter which host was involved in its delivery.
The only 'real' problem though with this approach is it requires a trusted path for the bank to get the "JP Morgan Chase root CA cert" into my hands (like a QR code they hand me physically). Serving it up over http: or over an unvalidated SSL context at first use seems to defeat the purpose since I could be being MitMd the first time I hit chase.com. In practice most people would be angry that they couldn't use the bank's website if their new phone or PC didn't have the certificate yet, and if places start advertising their cert QRs everywhere, it will normalize the idea that you add a CA certs all the time, leading to CA cert QRs being on billboards and bus stops and eventually fraudulent ones would be snuck in that way.
We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.
So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.
Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.
This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.
'Cos no scammer would ever be so sneaky as to leave off the tag... /s
> it up with whoever asked you to trust their key
'Cos no scammer would ever pretend to be that person... /s
As for tagging... We could use something like color to indicate domain. So if your well trusted plumber is giving financial advice maybe it shows up, but not in the "financial" color? Idk it seems like a solvable UX problem.