Add support for ed25519 keys

[ramonpetgrave64]

Client support for Rekor V2: sigstore-python

Summary

Resolves #1376, #1378

Adds support for ed25519 keys. In the cryptography library, is not yet any support for ed25519ph operations.

• https://cryptography.io/en/44.0.3/hazmat/primitives/asymmetric/ed25519/#

Fixes the CI test for timestamp-authority to use the latest release, not the latest tag, since we could have new tags without associated release artifacts to download.

Release Note

• Added support for ed25519 keys.
• CI: Timestamp Authority tests use latest release, not latest tag, of
  sigstore/timestamp-authority

Documentation

None

[ramonpetgrave64]

@woodruffw @jku

[jku]

LGTM. Getting this tested should be easy... I don't think there is any problem just editing the trusted_root/trustedroot.v1.json asset and making sure one of the keys is ed25519 (you could add a new log instance for example) -- the test only tests loading the key but it's better than nothing

[jku]

I'm marking "request changes" for the test: let me know if it seems to not be straight forward

[ramonpetgrave64]

@jku I tried to get sigstore-python to generate a ed25519 key for its signing certificate, changed all references from sha256 to sha512, but I still can't get it to work.

  File "/usr/local/google/home/rpetgrave/src/ssp/sigstore-python/sigstore/verify/verifier.py", line 374, in _verify_common_signing_cert
    raise VerificationError(f"invalid log entry: {exc}")
sigstore.errors.VerificationError: invalid log entry: checkpoint: invalid signature: keyring: invalid signature

I think the linters we use, mypy and ruff, are enough to be sure I didn't mistype or use incorrect method signatures.

[jku]

@jku I tried to get sigstore-python to generate a ed25519 key for its signing certificate, changed all references from sha256 to sha512, but I still can't get it to work.

I don't think using sigstore-python for key generation is a good idea:

$ openssl genpkey -algorithm ed25519 -out tmp.key
$ openssl pkey -in tmp.key -pubout
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAma70u3EPxalYWDfRh8jat6UwIQ9Mza9gGO2uNzqT5AE=
-----END PUBLIC KEY-----

I would expect something like that to work as the key value in trustedroot.v1.json. I'm just looking for a test that verifies that we are feeding load_der_public_key() something it expects to get in the ed25519 case (obviously we don't know 100% what ends up in the trustedroot but at least we'd document what type of value we expect to see)

[ramonpetgrave64]

@jku I added test case for the trusted_root that contains a the default tlog_key in rekor-tiles.

[jku]

Cheers, lgtm.

Testing changes are not really needed in changelog, but I don't mind: trimming the changelog down is easy when doing the release prep.

[jku]

/gcbrun

[woodruffw]

Clarifying: this is adding Ed25519 support at the trust layer, correct? Presumably we still need some API changes at the user sign/verify layers to support ephemeral Ed25519 keygen and signing.

[ramonpetgrave64]

@woodruffw yes, we still hardcore using an EC key for signing.