[HTTPS-Everywhere] Draft specification for file used to check for ruleset updates

[Jacob Hoffman-Andrews]

 > Instead of hashing a stringified version of the `update` object 
directly, we could sort an array of the keys in the update object and 
then create an array of key, value pairs in the sorted-key order.

Presumably, we would also want to recursively sort any sub-objects in 
the update object? What encoding do we use to serialize the update 
object for signing?

Your solution is definitely workable, but instead of using new (i.e. 
existing) tools, it means inventing our own tools, which are likely to 
be underspecified and have unique bugs.

Here are two alternatives that allow us to specify a signature over a 
byte sequence rather than canonicalized JSON:

1) The first line of the update file is a signature of the following 
bytes, up through the first newline. Everything following is valid JSON, 
and the signature is determined over those raw bytes. E.g.

uc0mBep1KTsWuJKpfF5LC8GPPa/Qy9+JfIAljVdBXIA=
{
   "foo": "bar"
}

2) The signature is not embedded in the JSON at all, but fetched from 
another file. e.g. /update.json and /update.json.sig.

Note that either of these approaches works with nsIDataSignatureVerifier.

Relatedly: We will probably want the extension to ping a certain URL 
when signature verification fails, so we can keep an eye out for 
malfunctions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140612/b1d64603/attachment.html>