`sigstore-tuf` README slightly inaccurate

[tnytown]

I'm looking at the README for sigstore-tuf and this section caught my eye:

Why not just use tough?

tough recomputes each key's TUF key ID over the entire key object (including non-standard fields like x-tuf-on-ci-keyowner) and rejects metadata whose declared key IDs don't match. That makes it unable to load GitHub's TUF root at all, even though python-tuf, go-tuf, and gh attestation all consume it fine. Per the TUF spec a key ID is an opaque, producer-chosen identifier — there is no requirement that keyid == hash(key). This crate therefore treats declared key IDs as authoritative and never recomputes-and-rejects.

A second, subtler interop requirement: TUF signs over securesystemslib / OLPC canonical JSON, not RFC 8785 JCS. The two differ in string escaping (notably newlines inside embedded PEM keys) and number handling, so this crate ships its own canonical encoder rather than reuse a JCS implementation.

The remark about RFC 8785 reads to me as part of the reasoning for rejecting tough. However, tough does in fact use a securesystemslib compatible OLPC style JSON canonicalizer (whew, what a sentence!)

If people agree that this is confusing, I'm happy to submit a PR adjusting the text myself!

[jku]

I'm not familiar with tough canonicalizer but it seems fine to omit that part of the README -- it also makes it sound like securesystemslib is somehow important here when the OLPC variant is actually part of the specification, securesystemslib just implements whatever is in the spec.

[wolfv]

Fine with me, too!