Xynnn_

@lukehinds Hi, ed25519 has been supported in https://github.com/sigstore/sigstore-rs/pull/87/commits/8314f8f7867e0e80c2e2ca0470a6897f859ae93c

Also, now `CosignVerificationKey` has the similar semantics with the `SigStoreSigner`'s public key. I'd prefer to add the following for ease * `Into` trait for `SigStoreSigner` or `KeyPair` * `From` trait...

There might need some refactoring for the key_interface, to deal with the following problems: * Now when users use the `signing_key` module, they must import the crates into the `Cargo.toml`,...

> @Xynnn007 Strongly agree about not having users import extra crates, thank you! Yea, in a sense `CosignVerificationKey` struct has the same issue that when use this we need to...

> As for the proposed API change, I like end users to not worry about which format the key they are importing might be. They just need to know if...

> Can you say more about why the InnerPublicKey struct is necessary? Could whatever that is doing be done with a trait on the PublicKey instead? I would assume the...

> Fine with me. I'm happy to remove the `ring` dependency. Let's just ensure the final refactoring will not degrade the developer experience for the consumers of the crate (translated:...

> Sounds good to me, as long as we implement as a mod (which I am sure is what you intend to do). Yes, after the signing key mod is...

Development plan: - [x] Impl `push` functions for `registry::ClientCapabilities` for the ability of communicating with OCI registry - [x] Impl basic architecture of OCI image-signing, including two modular parts: *...

> FYI that the OCI has finally approved the official mechanism for storing signatures a few weeks ago: https://github.com/opencontainers/wg-reference-types/ > > You'll likely need to switch to this over time...