The failure modes I was imagining are things like what happens if you visit a site and it is no longer serving signed content any more, or it's serving content signed by a key you haven't seen before? Either the user needs to be able to decide (based on information received out-of-band) which keys to trust, or you have to trust a site to never lose control of its keys (which reintroduces all the problems of HPKP, like ransoming).
Even in the happy path, there are questions of how you present to the user that the content has been signed (and by which key), separately from the guarantees that the TLS transport gives. Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app?
> Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app?
There do need to be standards for displaying such errors and requesting key verification in the browser. e.g. DNSSEC and DoH/DoT errors should also propagate up to the browser eh? How do web3 browsers handle keychains?
> Only users with package release permissions can create a new SoftwareRelease record for that project
You can log hashes to sigstore now, which is a centralized db supported by The Linux Foundation. https://sigstore.dev/ :
> How sigstore works: sigstore is a set of tools developers, software maintainers, package managers and security experts can benefit from. Bringing together free-to-use open source technologies like Fulcio, Cosign and Rekor, it handles digital signing, verification and checks for provenance needed to make it safer to distribute and use open source software.
> A standardized approach: This means that open source software uploaded for distribution has a stricter, more standardized way of checking who’s been involved, that it hasn’t been tampered with. There’s no risk of key compromise, so third parties can’t hijack a release and slip in something malicious.
> Building for future integrations: With the help of a working partnership that includes Google, the Linux Foundation, Red Hat and Purdue University, we’re in constant collaboration to find new ways to improve the sigstore technology, to make it easy to adopt, integrate and become a long-lasting standard.
But then DIDs and ld-proofs (with at least the current trust root in a trustless DLT of some sort) are even more standardized.
Software Releases, [Academic, Professional, Medical,] Credentials, Legal Documents, Server Certs, ScholarlyArticles: all of these things can be signed and may already be listed in the Use Cases documents for W3C DID Decentralized Identifiers [1] and W3C VC Verifiable Credentials [2] which are summarized in context to Keybase here: https://news.ycombinator.com/item?id=28814802
Notably: DNSSEC errors do not propagate up to the browser; when DNSSEC fails, sites simply fall off the Internet as if they never existed. It's a major fault of the DNSSEC design.
Unfortunately, because all domains don't yet have DNSSEC DNS records, a strict resolver that requires DNSSEC signatures will fall to resolve all domains unless it's configured to e.g. "allow-downgrade" to non-DNSSEC-signed records for any lookup.
FWIR, the same is basically true of DoH and DoT: if it's not configured to ~allow-downgrade, DNS will fall to resolve when connected to e.g. a captive portal hotspot; and there's no indication that DoH/DoT aren't working in the browser.
How do DNS resolution APIs need to change to accommodate basic DNSSEC and DoH/DoT error handling?
DoH and DoT don't have the same failure modes as DNSSEC --- a TLS failure during a DoH lookup is much more likely to actually be the result of a break in the chain of trust than a DNSSEC failure is.
Even in the happy path, there are questions of how you present to the user that the content has been signed (and by which key), separately from the guarantees that the TLS transport gives. Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app?