- From: Cristiano Longo <cristianolongo@opendatahacklab.org>
- Date: Sat, 17 Feb 2024 18:18:13 +0100
- To: public-swicg@w3.org
- Message-ID: <1f86db9b-3033-493b-bda7-bc2707200f63@opendatahacklab.org>
On 10/02/24 15:40, Cristiano Longo wrote: > > I written down some notes here > > https://cristianolongoodhl.github.io/clientsidehttpsignotes/ > > It is a github repository and any contribution will be very > appreciated, in particular w.r.t. security issues as the last time I > had to deal with security protocols was for my Master thesys several > decases ago. > > In the next here I'll add to these notes parts about client side > signatures. > > CL > Ok I think it is done. Please do with it whatever you want. https://www.opendatahacklab.org/src/viewArticle.php?url=..%2Fsitedata%2F20240217181310534931.md CL > On 07/02/24 17:46, Dmitri Zagidulin wrote: >> Ah wait, you meant the activity ID, not the signer ID. So, n/m, >> ignore my previous statement :) >> >> > There is no way to avoid this vulnerability without 1) making keys >> server-private or 2) throwing out HTTP Signatures entirely and >> resolving every incoming activity. >> >> Strongly disagree. The 'no way to avoid' is only that way due to >> possible mis-understanding on how client side sigs work on the side >> of current server implementers. >> >> >> On Wed, Feb 7, 2024 at 11:43 AM Dmitri Zagidulin >> <dzagidulin@gmail.com> wrote: >> >> > If clients have custody of keys, then `foo@example.com` could >> wait for `bar@example.com` to make a post, and then sign an >> activity with the same ID (e.g. "example.com/posts/102930 >> <http://example.com/posts/102930>") >> >> Wait, that's not how client signing works tho. The whole point of >> client signing is that nobody else can sign with the same ID >> (cause they don't have your keys). >> >>
Received on Saturday, 17 February 2024 17:18:27 UTC