6 ms·

I was wondering how much overlap the two technologies have too. What I'd really like to see supported is a way for a web app to specify a public key and a vers

I was wondering how much overlap the two technologies have too. What I'd really like to see supported is a way for a web app to specify a public key and a version number, and for the browser to then prompt you every subsequent time you access that page if the key or version number has changed. This would effectively allow web apps to use the same security model as desktop apps, i.e. TOFU. Arguably, though, auto-updating desktop apps are less secure than even TOFU, but I don't know users can be expected to judge whether v1.2.3 is more secure than v1.2.2, so perhaps the prompt doesn't provide any practical benefit.

westurner 5y ago
Is this solveable by including a cache key in the URL or other client-side storage?
- dane-pgp 5y ago
  Well, there is the SecureBookmarks trick[0], which uses integrity hashes and Data URLs, so you're right that signatures aren't strictly needed (especially at the HTTP level). I think the difficult part is the UX, and how to handle the failure modes, which is why browsers might reasonably be reluctant to support something like this. [0] https://github.com/coins/secure-bookmark https://github.com/coins/secure-bookmark
  - westurner 5y ago
    Are there additional HTTP status code-like error codes that need to be specified? What [same origin, SXG,] failure modes are there? From "HTTP 402: Payment Required" https://news.ycombinator.com/item?id=22214156 https://news.ycombinator.com/item?id=22214156 : > The new W3C Payment Request API [4] makes it easy for browsers to offer a standard (and probably(?) already accessible) interface for the payment data entry screen, at least. > https://www.w3.org/TR/payment-request/ https://www.w3.org/TR/payment-request/
    - dane-pgp 5y ago
      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?
      - westurner 5y ago
        You said HPKP and I misread it Re: HKP, WKD, GPG Linked Data signatures, Keybase+Zoom and ACME https://westurner.github.io/hnlog/#comment-28814802 https://westurner.github.io/hnlog/#comment-28814802 https://westurner.github.io/hnlog/#comment-26127879 https://westurner.github.io/hnlog/#comment-26127879 Ctrl-F "trillian" re: CT cert grant and revocation events on a blockchain > Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app? blockcerts/cert-verifier-js ?
        westurner 5y ago
        > 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? https://github.com/blockchain-certificates/cert-verifier-js#verify-a-blockcert-certificate https://github.com/blockchain-certificates/cert-verifier-js#... From (an obscure comment with pictures on) "Roadmap update for TUF support " https://github.com/pypa/warehouse/issues/5247#issuecomment-913052362 https://github.com/pypa/warehouse/issues/5247#issuecomment-9... : > 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/ 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 https://news.ycombinator.com/item?id=28814802 [1] https://www.w3.org/TR/did-use-cases/ https://www.w3.org/TR/did-use-cases/ [2] https://www.w3.org/TR/vc-use-cases/ https://www.w3.org/TR/vc-use-cases/

westurner 5y ago

Is this solveable by including a cache key in the URL or other client-side storage?

dane-pgp 5y ago
Well, there is the SecureBookmarks trick[0], which uses integrity hashes and Data URLs, so you're right that signatures aren't strictly needed (especially at the HTTP level). I think the difficult part is the UX, and how to handle the failure modes, which is why browsers might reasonably be reluctant to support something like this. [0] https://github.com/coins/secure-bookmark https://github.com/coins/secure-bookmark
- westurner 5y ago
  Are there additional HTTP status code-like error codes that need to be specified? What [same origin, SXG,] failure modes are there? From "HTTP 402: Payment Required" https://news.ycombinator.com/item?id=22214156 https://news.ycombinator.com/item?id=22214156 : > The new W3C Payment Request API [4] makes it easy for browsers to offer a standard (and probably(?) already accessible) interface for the payment data entry screen, at least. > https://www.w3.org/TR/payment-request/ https://www.w3.org/TR/payment-request/
  - dane-pgp 5y ago
    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?
    - westurner 5y ago
      You said HPKP and I misread it Re: HKP, WKD, GPG Linked Data signatures, Keybase+Zoom and ACME https://westurner.github.io/hnlog/#comment-28814802 https://westurner.github.io/hnlog/#comment-28814802 https://westurner.github.io/hnlog/#comment-26127879 https://westurner.github.io/hnlog/#comment-26127879 Ctrl-F "trillian" re: CT cert grant and revocation events on a blockchain > Does there need to be a UI for viewing the key details, and for approving/rejecting upgrades to the web app? blockcerts/cert-verifier-js ?
      - westurner 5y ago
        > 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? https://github.com/blockchain-certificates/cert-verifier-js#verify-a-blockcert-certificate https://github.com/blockchain-certificates/cert-verifier-js#... From (an obscure comment with pictures on) "Roadmap update for TUF support " https://github.com/pypa/warehouse/issues/5247#issuecomment-913052362 https://github.com/pypa/warehouse/issues/5247#issuecomment-9... : > 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/ 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 https://news.ycombinator.com/item?id=28814802 [1] https://www.w3.org/TR/did-use-cases/ https://www.w3.org/TR/did-use-cases/ [2] https://www.w3.org/TR/vc-use-cases/ https://www.w3.org/TR/vc-use-cases/