Re: HTTP Signature CG report

I'm solely suggesting that investigating the client-side signature 
approach, also with reporting the security issue provided by nightpool, 
would make the report more exhaustive.

CL

On 07/02/24 18:03, Dmitri Zagidulin wrote:
> > I think we're probably significantly off-topic for the thread in 
> question then,
>
> Yeah, hehe, agreed, sorry bout that.
>
>
>
> On Wed, Feb 7, 2024 at 12:03 PM nightpool <eg1290@gmail.com> wrote:
>
>     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 <http://example.com> to say that mallory's key is
>     valid only for URIs starting with example.com/@mallory/
>     <http://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 <http://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
>                 <http://example.com/users/foo>, but it purports to
>                 shares an id (example.com/posts/123
>                 <http://example.com/posts/123>) with a legitimate post
>                 made by example.com/users/bar
>                 <http://example.com/users/bar>. There is no way a
>                 receiving server can tell that example.com/posts/123
>                 <http://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
>                     <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).
>
>