Re: HTTP Signature CG report

I think we're probably significantly off-topic for the thread in question
then, which is about a CG report on the current state of HTTP Signatures
within the fediverse. The scheme you're proposing would require two keys
(one for the actor to sign client-side, and another for the server to sign
to verify that the origin https://example.com has been used correctly), or
a delegated key with some kind of ID prefix (i.e. some way for example.com
to say that mallory's key is valid only for URIs starting with
example.com/@mallory/).

On Wed, Feb 7, 2024 at 11:57 AM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> Also, let me back up and try to address this on a slightly more abstract
> level.
> Server-side signing is a TEMPORARY state of affairs. Like.. it's not good,
> it's just an artifact of tech limitation (lack of good client-side key
> management options) at the time.
> And it's definitely not the "only secure method" that the previous
> discussion is implying, but exactly the opposite (something we have to put
> up with currently, but will try to move away from).
>
> If current server implementations don't handle client-side signing
> correctly, that's fine, we'll have to fix that (and painfully wait till the
> fixes propagate through the ecosystem).
> If there's something in the AP protocol that's adding to the confusion /
> making client-side signing harder, we'll fix the protocol.
>
> (Hopefully my answers make more sense in that context.)
>
>
>
>
> On Wed, Feb 7, 2024 at 11:49 AM Dmitri Zagidulin <dzagidulin@gmail.com>
> wrote:
>
>> > There is no way a receiving server can tell that example.com/posts/123 is
>> "supposed to" be bar's ID to sign, instead of foo's.
>>
>> And why's that a problem? (also, let's switch to the usual Alice for
>> legit post author and Mallory for the attacker).
>> If Alice creates a post and client-side signs it, and then Mallory makes
>> a post with the same ID and client-side signs it and sends it to another
>> server -- you're right that the receiving server doesn't know who the post
>> is "supposed to" belong to.
>> However, that doesn't really matter. People who don't subscribe to
>> Mallory won't see her posts (they'd only see Alice's posts). Is that not
>> the case?
>>
>>
>>
>>
>> On Wed, Feb 7, 2024 at 11:46 AM nightpool <eg1290@gmail.com> wrote:
>>
>>> I'm talking about the ID for the activity itself. The Activity is
>>> attributedTo example.com/users/foo, but it purports to shares an id (
>>> example.com/posts/123) with a legitimate post made by
>>> example.com/users/bar. There is no way a receiving server can tell that
>>> example.com/posts/123 is "supposed to" be bar's ID to sign, instead of
>>> foo's.
>>>
>>> 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")
>>>>
>>>> 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).
>>>>
>>>>
>>>>