FWIW, Mozilla's current objections to the standard don't really make sense. See: https://github.com/mozilla/standards-positions/issues/29#iss...
It seems the real issue at the moment is that it just isn't a high priority for them.
Thanks for the link! Subscribed.
> 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?
Instead of ugly "https://www.google.com/amp/www.example.com/amp.doc.html" links as it displays them now when clicking AMP result on Google.com it would display "https://example.com/amp.doc.html" even though example.com was not contacted at all.
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/