Re: HTTP Signature CG report

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).
>>
>>