Uppercase keyids throw off reference implementation

[trishankatdatadog]

Description of issue or feature request:

If an integrator accidentally passes uppercase keyids in the public keys given for a step, the reference implementation does not realize that they should be the same as lowercase keyids.

Current behavior:

An uppercase keyid in the pubkeys for a step will break verification, even if that files with the lowercase keyid exist.

Expected behavior:

All keyids should be normalized internally, so that uppercase == lowercase keyids (unless I'm missing some subtle security attack, which I don't see right now).

[lukpueh]

Thanks for filing the issue, @trishankatdatadog. Does "throw off" mean that in-toto treats keyids in a case-sensitive manner? To me this sounds like expected behavior.

For comparison, step names are also case sensitive. E.g. a step in a layout with name "foo" and authorized pubkeys [8ba69b87d43be294f23e812089a2ad3c07d962e8] will only accept a link file with filename "foo.8ba69b87.link" which has a signature with a keyid "8ba69b87d43be294f23e812089a2ad3c07d962e8", with no variation in case allowed.

I do, however, agree that there is a slight inconsistency with gpg keyids, which are treated in a case insensitive manner when passed to in_toto_run as link signing key, or in_toto_verify as layout verification key. The reason is that these keyids are passed on to the gpg command line tool, which is pretty lenient in what it accepts to identify a key.

@SantiagoTorres, how do you think keyid case should be handled?