Allow Repositories to Specify Hash Algorithm

[vladimir-v-diaz]

We should consider allowing repositories to specify, in metadata, the algorithm used when generating path hashed paths in section 4.5 of the specification

• KEYIDS is currently fixed to SHA-256 in the specification. Should we allow flexibility in this case?
• path hash prefixes is currently fixed to SHA-256.
• The hash algorithm(s) for digests prepended to consistent snapshots are set by the repository and listed in the hashes key of each metadata file. For example, https://github.com/theupdateframework/tuf/blob/develop/examples/repository/metadata/timestamp.json#L15

[JustinCappos]

As opposed to allowing one to use different hash algorithms for different
packages or to allow one to have multiple hashes used on the same package?

I think the intent is that both of the above cases should be supported by
TUF. (In practice, it's not clear if either will occur.)

We do need to clearly describe what clients should do when encountering a
hash type they do not know how to check. I do not think this is clearly
stated now.

On Fri, May 1, 2015 at 10:46 AM, Vladimir Diaz notifications@github.com
wrote:

Should the TUF specification restrict repositories to one particular hash
algorithm?

We should consider allowing repositories to specify, in metadata, the
algorithm used when generating hashed paths in section 4.5 of the
specification
https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt

—
Reply to this email directly or view it on GitHub
#272.

[vladimir-v-diaz]

For the generation of KEYIDS and path hash prefixes, the specification restricts the hash algorithm to SHA-256. I think we should be more flexible in this case.

[JustinCappos]

Are you proposing we would list the hash algorithm there too?

On Fri, May 1, 2015 at 1:59 PM, Vladimir Diaz notifications@github.com
wrote:

For the generation of KEYIDS
https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L476-L477
and path hash prefixes
https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L615-L617,
the specification restricts the hash algorithm to SHA-256. I think we
should be more flexible in this case.

—
Reply to this email directly or view it on GitHub
#272 (comment)
.

[vladimir-v-diaz]

I'm not sure yet where we should list the hash algorithm used to generate path hash prefixes and the digest prepended to consistent snapshots. I think listing the algorithm in root.json metadata here is one option.

[vladimir-v-diaz]

For KEYIDS, I think saying that SHA-256 is an option should be fine.

[JustinCappos]

Yes, the root.json seems like the most logical thing to me too.

On Fri, May 1, 2015 at 2:47 PM, Vladimir Diaz notifications@github.com
wrote:

I'm not sure yet where we should list the hash algorithm used to generate
path hash prefixes and the digest prepended to consistent snapshots
https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L801-L802.
I think listing the algorithm in root.json metadata here
https://github.com/theupdateframework/tuf/blob/develop/examples/repository/metadata/root.json#L11
is one option.

—
Reply to this email directly or view it on GitHub
#272 (comment)
.

[vladimir-v-diaz]

We now allow metadata to specify the hash algorithm(s) that are used to generate keyids.

writing...
https://github.com/theupdateframework/tuf/blob/0ce016b7b19a0fc15443eed657a90246ec5df0aa/tuf/keys.py#L514-L529

loading...
https://github.com/theupdateframework/tuf/blob/0ce016b7b19a0fc15443eed657a90246ec5df0aa/tuf/client/updater.py#L538-L561

metadata example...
https://github.com/theupdateframework/tuf/blob/0ce016b7b19a0fc15443eed657a90246ec5df0aa/tests/repository_data/repository/metadata/root.json#L47-L55

[trishankkarthik]

Hello Vlad,

On 28 October 2016 at 12:53, Vladimir Diaz notifications@github.com wrote:

metadata example...

https://github.com/theupdateframework/tuf/blob/
0ce016b/tests/repository_
data/repository/metadata/root.json#L47-L55

I've a question! I never understood that example. There seems to be one
keyid, but two hash algorithms. Is the client supposed to try both
algorithms to see which one yields the key id?

Thanks,
Trishank

[vladimir-v-diaz]

That's correct, one keyid is listed in metadata (along with 1 or more hashing algorithms). The keyid(s) are generated by hashing a key object:

{"keytype": "ed25519",
    "keyval": {
     "public": "0692a846935833d685168ae8c98fee951d52d8aa76685b8ba55b8e1eada217c2"}

Let's look at an example...
https://github.com/theupdateframework/tuf/blob/0ce016b7b19a0fc15443eed657a90246ec5df0aa/tests/repository_data/repository/metadata.staged/targets.json#L11-L22

The client first extracts the key object on lines 18-20 and generates SHA256 and SHA512 digests (because that's what's specified on lines 14-16). It should then verify that the default keyid listed on line 13 matches the digest the client generated locally. If it does, the client associates this key with the SHA256 and SHA512 digests that it generated. In the future, the client can lookup a key and validate signatures by querying for either of these two KEYIDs.

Either the SHA256 or SHA512 keyid can be listed in signatures fields, or the "keyids" field of delegations. The client can identify a keyid and its associated key by calling tuf.keydb.get_key(keyid). If it finds it... good. If not, that keyid / key / signature is not trusted.

[trishankkarthik]

Ah, I see. So it's about options. As long as one expected keyid is in there, good. Thanks!