| JanZerebecki added a comment. |
In T138708#2426549, @daniel wrote:In T138708#2424766, @JanZerebecki wrote:Why use a sha1 instead of inlining the normalized serialization in the text to sign?
Because that doubles the size of the serialization of a statement.
Would that part need to be stored?
I would suggest to store it. It's also possible to reconstruct it.
If the sha1 is used how do you reconstruct what it was composed of?
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?
Why add the signer's identity?
It should be visible *somewhere*, right?
Why is the one in the GPG signature not sufficient?
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.
How do you revoke a signature?
By removing the snak that contains the signature.
Then how do you counter replaying the signature?
The revision ID in the signed text would mismatch the revision in which the signature was added.
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?
Or by revoking the key.
What to do about all the other signatures that the signer wants to convey they think are still true?
I didn't think about revoking individual signatures when I wrote this proposal... Maybe it would be possible to include a token in the signed text, and the signer could maintain a (signed) list if valued resp of revoked tokens in a well known location? Maybe the token is a URL that resolves to a (signed) "valid" or "invalid" response? How do other systems solve this?
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 .
How do you guard against being able to send the user only a selective part of the signatures?
Can you elaborate?
If you carefully select only some true statements will a conclusion based on them change in your intended way?
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?
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 Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
