Re: ActivityPump and signature / origin verification

Jason Robinson writes:

> Hi,
>
> Yes I was thinking of moving the discussion into a few issues on github 
> - holidays too ;)
>
> To me, content verification is pretty much central in any attempt to 
> have a federation protocol - so I'm not sure how it could be outside 
> scope ;) I understand there is want to use something that is also a 
> standard and if there are two ways to go forward, that might be 
> problematic. I don't really know either one, I'm just used to the good 
> old and works way of reading a public key from the users profile and 
> then verifying the content which is signed with the users private key. 
> All protocols I've come across use good old public/private keys. I must 
> confess this is not that many protocols, but to me this is a very simple 
> and effective way - it is old technology which is proven and available 
> everywhere and also easy to use. I'll post an example workflow from 
> diaspora* into github.
>
> The only problem I see with pubkey/private key -way is that is you lose 
> your private key, you pretty much lose your identity - or at least 
> ownership of any old content pushed out remotely. I'm not sure if the 
> new signature methods being discussed solve this problem somehow.

I don't know the history to know why the objections to signatures have
been so strong.  But perhaps others in the group do.  Would someone else
like to chime in?

We do have *a* method of verification, it's just not a very good one,
because it doesn't rely on signatures and requires phoning back to the
original source.  I agree that signatures would be better.

I feel like my hands are tied here though in terms of making something
official.  Jason, would you be interested in collaborating in something
unofficial?

>> Despite what I just said above, the signature aspect is important to me,
>> and I agree that we shouldn't do anything that prevents clear solutions
>> from being adopted once what they exactly are gets sifted through
>> clearly.  Hence me adding the "if other generally agreed upon mechanisms
>> for handling verification become available in the future, servers are
>> welcome to use those methods, in the future" phrasing.
>>
>> If you're worried this SHOULD NOT still blocks it, I can change it.
>
>
> The problem is that you can't remove the SHOULD NOT unless something 
> else is offered in place. An even worse spec would be that would not 
> provide a good way for verifying content authorship - leaving it 
> completely open to the implementer. This is one of the most critical 
> things imho in the whole idea of pushing content around - how to make 
> sure the person really wrote that?
> 
> On the other hand, leaving that in, it would be impossible to build for 
> example something like diaspora* purely with the protocol. And adding 
> anything on top would make it largely incompatible with the rest of the 
> implementers that enforce different trust requirements.
>
> Anyway, will file some issues in github, better than mailing list :)

There are two concerns here:

1. That saying SHOULD NOT effectively blocks *any* signature based
   verification.
2. That a method of signature based verification is not specified,
   meaning that in reality we'll have incompatibilities between instances.

As for #1, I've revised the text in a way that I think makes more
explicitly clear what is meant.  The "SHOULD NOT" is preserved, but
"without some form of verification" is added.  I think this makes it
clear that options are open to signature based verification if it's
mature enough.

-      In particular, servers SHOULD NOT trust client submitted content, and federated servers also SHOULD NOT trust content received from a server other than the content's origin.
+      In particular, servers SHOULD NOT trust client submitted content, and federated servers also SHOULD NOT trust content received from a server other than the content's origin without some form of verification.

As for #2, as I said, I feel like we don't have a lot of leeway here.
We're in the same boat here (sort of) that we are with authentication.
Technically, in order for both the client to server and federation
aspects of this protocol to work, we need to have an agreed-upon way of
doing authentication, but also it's been made clear that we need to
leave the actual mechanisms of this out of scope of the documents.

Except, I guess, that the document actually acknowledges that
authentication is needed, and doesn't acknowledge that signature
verification is :)

Anyway, I hope the wording change helps, and happy to talk further.

Received on Thursday, 7 January 2016 14:36:44 UTC