Canonical policy file

[geky]

Just an idea for improving user interaction with policy files.

One of the underlying ideas of Veracruz is that we can use the hash of the policy file to ensure that all participants in the system are following the same rules. But the way this is currently implemented includes whitespace/formatting, meaning policy files like these are treated as different:

{
    "sinaloa_url": "127.0.0.1:3012",
    "enclave_cert_expiry": { "year": 2022, "month": 1, "day": 13, "hour": 19, "minute": 5 },
}

{
    "sinaloa_url": "127.0.0.1:3012",
    "enclave_cert_expiry": { "year": 2022, "month": 1, "day": 13, "hour":19, "minute": 5 },
}

Instead of hashing the formatted json, what if we first minified the json, then hashed. Giving us a sort of "canonical" hash that shouldn't change unless the underlying data changes.

This would also make is fairly straightforward to add other formats such as toml and yaml.

It could also be possible to define a canonical representation for all fields, ensuring semantically equivalent policies hash to the same hash, but this would require a bit more work. Though it would have the benefit of moving those corner cases into a single policy parser.

Thoughts?

[ShaleXIONG]

We can concat all the fields (as string literal) in a defined order then hash. This will allow us, as you mentioned, to include other types of policy file but they all have the same hash. I believe we can add a get_hash method in policy.rs in veracruz-util for computing the hash. We then can add methods like from_toml and from_yaml to read in other forms of input.

[dreemkiller]

Before we decided whether to do this we need to know what real problems we are solving. I understand and share the theoretical distaste for allowing whitespace or ordering changes to affect the hash, but in what ways do we expect users to experience this?

I don't imagine users are going to be editing the order of a file themselves after the policy is agreed upon (why would they?).

One real-world case that comes to mind is line-endings getting mangled by editors/transport mechanisms/etc

Any others?

[geky]

My main thought was reducing surprise for users. Since the policy file is expected to be human modified at some point in it's lifetime, it could be surprising to a user if they open the policy file to check that it's sane, and then their editor automatically deletes trailing whitespace on close.

[ShaleXIONG]

That is a good question. I can imagine that participants or principals audit and eventually agree on the policy file, including all the white spaces, etc. If no principal accidentally edits their local policy file, then even the white space should match. One possible situation is dynamic policy which requires the canonical hash.

[geky]

Another option, we could use a different file extensions (.policy?) to hint that the file is more sensitive than a normal .json file.