|
|
|
|
|
|
by buboard
2381 days ago
|
|
|
i agree but i just can't justify the connection between the domain and signed content. The root node here is "X's key" and it is used to sign a domain cert and also a document. It's semantically wrong for the browser to pretend that the document belongs to the domain, and even more wrong when the signed document is being served by another domain with a completely different cert, google's! Even app stores don't do that - if you download a signed app from any domain, it won't pretend it s downloaded from apple.com but it will report that its signed from Apple Inc. The situation is not analogous anyway because there are very few app stores from 3-4 highly trusted corporates. If any of their app store private keys are stolen the internet is fucked. |
|
|
Browsers "pretend" exactly this every time they download a page via HTTPS. It's how HTTPS works. Did you think that they trust that the content comes from the correct source by just doing a reverse DNS lookup on the IP address? They don't. Instead, they check a signature from the web server against their cert keystore, and if the PKI signature check fails, you get a big scary warning that the connection isn't secure/private. The same thing would happen with SXG based content if the signature didn't match the keystore, except the signature to be checked is carried with the content itself, just like with PGP/GPG.
> Even app stores don't do that - if you download a signed app from any domain, it won't pretend it s downloaded from apple.com but it will report that its signed from Apple Inc.
I just checked an iPhone, and they appear to attribute an app to the creator, not Apple, Inc.
But the reason they don't show a download domain is because consumer iOS apps can only be downloaded from Apple, from the App Store, and nowhere else. Adding the information about download source information to the iOS UI would be totally redundant as the value would always be 'downloads.apple.com' or whatever.
If you look at the actual cert signing procedure for iOS apps, the configuration step includes the domain, which is why Apple can associate an entity's apps with it's https websites. Nonetheless, the apps are still signed by the app's creator, not Apple, and the app's creator is responsible for securing the private keys [1]
> The situation is not analogous anyway because there are very few app stores from 3-4 highly trusted corporates.
Why should only the 3-4 big corporates be the only entities who can sign or distribute apps or static web content? They are not the only entities capable of securing private keys. Banks do it all the time, as do individual app developers (note the warnings to app developers about private key management on Apple's website). They are also not the only entities capable of distributing content. App and content stores can provide many other services of added value, like aggregation and curation and payment systems, but signing and distributing content isn't one of those services they can uniquely provide.
You could even argue that distributing the ability to sign and distribute content away from the big corporations reduces single points of failure and makes the whole content distribution ecosystem more robust and fault tolerant.
1. https://developer.apple.com/support/certificates/