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

[Red]

On 2014-06-12, 12:11 PM, Yan Zhu wrote:
> On 06/12/2014 08:57 AM, Red wrote:
>> On 2014-06-12, 7:18 AM, Jacob Hoffman-Andrews wrote:
>>>> 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?
>> We actually sign the hash of `updateObj.update` (that is, the flat
>> update object inside the outer object).  You can see what I've done to
>> handle this automatically in the utility I built to handle most of the
>> process of creating the update.json file contents:
>> https://github.com/redwire/https-everywhere/commit/eaff57798a5682ec6171ef5c86a65df8b06c174b
>>
>> As I mentioned in my previous email, because we have decided not to use
>> a nested structure for the update object and are instead going to serve
>> different update.json files from different URLs, there isn't currently a
>> need to recursively convert objects inside `update` to a list of key,
>> value pairs.  If that changes at some point, it wouldn't be hard to
>> implement, though.
> That still leaves open the question of how to serialize the array of
> keys. As mentioned before, there is no guarantee that JSON.stringify is
> deterministic across versions/environments. A quick Goog. search
> suggests that various people have come up with variously-convoluted
> solutions to this problem, including in more-or-less in the way you've
> mentioned:
> https://stackoverflow.com/questions/8931967/is-there-a-deterministic-equivalent-of-json-stringify
>
> It might be a pain to always make sure that our js object serialization
> code gives the same result across different Firefox releases, for instance.
>
> Given this, I'm leaning toward Jacob's solution of taking the signature
> over the raw bytes in the update JSON file, either as the first line in
> the update file or as a detached .sig.
If we were to serve a separate file containing the signature over the
raw bytes of the update.json file, wouldn't we also need to provide some
assurance that the contents of that file haven't been falsified, i.e.,
have a hash available or something, as well? I might not understand the
security requirements in this case well enough, but I get the impression
that this would effectively lead us to an infinite loop of fetching a
file with some verification data, and then needing a new file to provide
proof of the validity of that data and so on.

As I understand our requirements, appending the signature to the first
line of update.json might work out, since it'll be a signature of the
content to follow and shouldn't be tamper-able.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 341 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140612/936fe17a/attachment.sig>