[danans]

No, you can distribute whatever content you want. But the content distribution network can't listen for posts from those forms when the content is rendered.

SXG doesn't answer DNS requests for your domain. It only says that a particular piece of content has been signed using private keys that have been registered with the displayed host. That's it.

In fact, you don't even need a CDN or DNS to distribute SXG content. You could distribute it via USB drives, or code flags, USB drives attached to messenger pigeons, whatever. The point is that authenticity of the origin of the content is completely independent of how the content got to you.

When that SXG content, however it is distributed, is rendered, the browser represents that content as originating from your domain, which is in fact exactly where it originated.

[buboard]

There are 100 ways to steal credentials if you manage to convince the user that it’s safe to start typing in the page, since you can serve malicious js that way.

I really don’t understand why the browser would masquerade the url just because the content is signed. At best it is able to say ‘the content is signed with x’s key’

[danans]

> There are 100 ways to steal credentials if you manage to convince the user that it’s safe to start typing in the page, since you can serve malicious js that way.

That's true, but it's completely independent of SXG. There's no way to trick SXG into showing a URL that it's not signed for. You would have to steal the private keys.

> At best it is able to say ‘the content is signed with x’s key’

Remember that x's key is cryptographically associated with their domain - that's how web certs work - so the browser can also say that "this content is signed with domain x's key". That's exactly what happens with https today, but with https, the chain of attribution implied by the signature stops at the webserver, since it holds the private keys for signing the content.

SXG allows the chain of attribution to be completely independent of the transport mechanism, https or otherwise. Of course, you should still use https to encrypt during data transmission over the internet, but that's orthogonal to content signing.

This is also directly analogous to how app stores distribute cryptographically signed apps. For example, it allows an iPhone to open a local native iOS app in response to a URL click in web content [1]: The app and the URL are both cryptographically signed by the same entity, so iOS can conclude that they are from the same origin, and allow the app to handle the URL.

1. https://developer.apple.com/library/archive/documentation/Us...

[buboard]

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.

[danans]

> 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

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/

[buboard]

Well thanks for your reply , i still think sxg breaks semantics.

> Browsers "pretend" exactly this every time they download a page via HTTPS.

yeah and the big scary warnings are for the connection, not the content. currently browsers tie url host to DNS so the semantics are different, so the cert certifies the distributor. I also think this is only true for certs that don't have an organization name, at least i think that , for extended-validation SSL they still show this: https://upload.wikimedia.org/wikipedia/commons/6/63/Firefox_...

> and they appear to attribute an app to the creator, not Apple, Inc.

indeed , i meant that they attribute the app to Apple Inc as the creator, but not their domain, which is again, different semantics. (although i suppose apple is somehow involved in ensuring that the correct binary is distributed for every developer)

> Why should only the 3-4 big corporates

i m obviously not saying they should , but that it's not analogous situation, with their walled gardens and all. the web is nobody's a walled garden and a large part of the content is public domain which doesnt need any signing. that s why app store logic doesnt apply.

> reduces single points of failure

that 's what software hosts already do with providing hashes for binaries. and it's great that sxg can verify content through the browser. but it shows where the content was created, not where it was distributed , thats why i think it's wrong to change the URL

there is also a laundry list of dangers that they introduce that seem pretty serious for something that is being pushed forward for basically cosmetic reasons: https://blog.intelx.io/2019/04/15/a-new-type-of-http-client-...