top | item 19377190

(no title)

nes350 | 7 years ago

SXG[0] looks promising - allows signing (and subsequently caching externally) whole HTTP exchanges.

This may be useful for improving security, especially of CDNs. Binary Transparency seems to be one of the use cases mentioned in the spec[1] - perhaps someday this would be used for an unified scheme for signing application packages/updates, without reinventing the wheel every time.

[0]: https://developers.google.com/web/updates/2019/03/nic73#sgx

[1]: https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

discuss

order

Leace|7 years ago

SXG is primarily designed for AMP so that the browser can display the origin in the address bar while the content is being served from Google.

Currently only one CA provides paid certificates with a special extension so that the cert can be used to sign SXG files [0].

[0]: https://www.digicert.com/account/ietf/http-signed-exchange.p...

As for binary transparency it's not enough to stamp the certificate (that's what CT logs do). The artifact would have to be stamped and published in a widely accessible source. Actually Binary Transparency doc published by Mozilla [1] creates a new regular certificate for new published binary thus utilizing CT infrastructure as it is today.

[1]: https://wiki.mozilla.org/Security/Binary_Transparency

If we're at Mozilla, it's also interesting to see what's their position on SXG [2]. There is only one spec there with that status there.

[2]: https://mozilla.github.io/standards-positions/

OrgNet|7 years ago

> SXG is primarily designed for AMP so that the browser can display the origin in the address bar while the content is being served from Google.

Displays the origin of the content?

kinlan|7 years ago

> unified scheme for signing application packages/updates

This is one of our longer term visions for the API, not there just yet.