| daniel added a comment. |
In T138708#2427828, @JanZerebecki wrote:By normalizing the serialization of the statement of the revision in which the signature was added.
That makes it impossible to detach it, i.e. signatures need to be in the items. That limits the amount of signatures that are easily handled, is that your intention?
I don't see why that would make it impossible to detach it.
Storing the signed text as a reference in the statement is indeed a scalability issue. It's a cost I would be willing to pay to keep implementation simple. As the proposal stands, it could even be implemented as a Gandget, with no backend support. The assumption was that the use case would be a handful of well known authorities signing things in their domain. If we want to scale this to hundreds of signatures per statement, so people can build a "truthy bubble", a bit of dedicated server side infrastructure would be needed. If the need arises, I'm all for it, but we should start small and simple.
It might be sufficient, but it's typically an email address. We may want something more meaningful - maybe even an ItemId.
No, it is not an email address, see https://tools.ietf.org/html/rfc4880#section-5.2.3.5 . The SHOULD NOT in https://tools.ietf.org/html/rfc4880#section-3.3 needs consideration, though. I think that RFC gets it right that the signers identity is not bound directly to anything besides crypto, binding to more info can be done by indirection through a signature.
That indirection is what I had in mind. But if there are better mechanisms that the one in the original proposal, sure, let's use them.
However, maybe we don't want to counter this. If someone vandalizes the item by removing the statement, or even just the signature, we want to be able to restore it, I suppose.
If replaying signatures is not countered then cryptographically revocation is not working. If revocation is not allowed, then how will a signer correct errors?
I was thinking about the issue while I was typing. I think revokable tokens (in the form of URLs) are the best way to achieve this. But it requires some infrostructure on the side of the signer. An alternative to tokens would be to use many separate subkeys that can be revoked without too much colatteral damage. If the signer uses one subkec per 100 statements, they would have to re-sign 99 statements to revoke one.
GPG certifications (what is used to sign someones key) can be revoked. Synchronization is done through keyservers, though I don't know how far the weaknesses in that weakens the rest of all this. Do you? See also https://en.wikipedia.org/wiki/Outside_Context_Problem , https://en.wikipedia.org/wiki/Eventual_consistency and https://en.wikipedia.org/wiki/Revocation_list#Problems_with_CRLs .
No, I have not looked at the details. As far as I know, the infrstructure exists, but doesn't work too well in practice.
It's theoretically possible to construct a misleading data set from cherry-picked signed statements. I don't think this method could be used to make it appear that a signer asserted something they did not intend to assert. Do you have an idea how such a situation could be constructed?
Theoretically? Is lying by omission only theory?
No, it's common practice. The question is if it's practical in this context.
We could support signing groups of statements, maybe even across items, to prevent this. That gets a lot more complicated, though. Keeping the spec for signed statements simple is important for getting it adopted. If we can keep it open for cross-statement siignatures, great! One option would be to have sections in the sigend text, one per statement ID (that is, ItemID + statement uuid). Then you can easily sign multiple statements together. But then there is no obvious place to store the signature for now.
Cc: jayvdb, Scott_WUaS, tfmorris, Spinster, TomT0m, Denny, Eloquence, JanZerebecki, T.seppelt, Aklapper, daniel, Zppix, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
