An experimental Rust crate for sigstore

Summary

Due to https://github.com/sigstore/sigstore-rs/issues/27. This pr removed ring crate, and use RustCrypto crates instead.

Release Note

• replaced ring crate with RustCrypto
• refactored CosignVerificationKey implementation and interface
• fixed the code which references CosignVerificationKey
• added RSA keys and signing algorithms support (RSA PSS & RSA PKCS#1 v1.5)

API Changes

• Changed all the from_XXX functions for CosignVerificationKey's SignatureDigestAlgorithm parameter into SigningScheme
• Deleted the enum SignatureDigestAlgorithm
• Replace struct CosignVerificationKey into enum.

Documentation

Much like the go counterpart in sigstore/sigstore, implement key generation and a signer interface. This should provide the following:

1. Generate of a key pair using a provided alg (rsa, ecdsa)
2. public key derive from private key
3. Signing interface
4. Serialisation (handle PEM / DER en/decode etc).

Summary

Due to https://github.com/sigstore/sigstore-rs/issues/27, sigstore-rs needs key generation and signing interfaces.

This pr aims to give a framework for signer and key pairs.

The KDF refers to go counterpart in sigstore/sigstore

Release Note

• Definition of interface for key generation, derivation of private and public keys and signing.

The interface for KeyPair included:

fn public_key_to_pem(&self) -> Result<String>;
fn public_key_to_der(&self) -> Result<Vec<u8>>;
fn private_key_to_encrypted_pem(&self, password: &[u8]) -> Result<Zeroizing<String>>;
fn private_key_to_pem(&self) -> Result<Zeroizing<String>>;
fn private_key_to_der(&self) -> Result<Zeroizing<Vec<u8>>>;

And a Signer

fn key_pair(&self) -> &dyn KeyPair;
fn sign(&self, msg: &[u8]) -> Result<Vec<u8>>;

• ECDSA was implemented.

let ec_key_pair = EcdsaKeys::<p256::NistP256>::new().unwrap();

• For easy to use signing schemes, use an enum interface, like

let signer = SigStoreSigner::new(SigningScheme::ECDSA_P256_SHA256_ASN1).unwrap();
let sig = signer.sign(b"test message").unwrap();

Documentation

NONE

Summary

This PR helps to implement OCI Image Signing due to https://github.com/sigstore/sigstore-rs/issues/125.

But please notice that this PR only uses the OCI Spec v1.0 (instead of v1.1, which brings referrer mechinism)

Release Note

• Added push related functions for ClientCapabilities and related impls
• Fixed a bug when converting sigstore::ClientConfig into oci_distribution::ClientConfig
• Fixed a bug when parsing a private key file RSA was not considered.
• Added some Debug, ToString, Eq, PartialEq macros and functions to enums and structs of crypto mod.
• Refactored SimpleSigning as a sub module for payloads
• Added OCI Image signing support together with some unit tests and examples.
• Changed signature field of SignatureLayer into an Option, which helps when we meet a SignatureLayer that is to be signed.
• Added a switch of http/https when access a registry for examples/cosign/verify

Documentation

Please see the examples/cosign/sign/README.md for the guide of OCI Image Signing.

Description

Fulcio has updated its certificate. Right now, inside of Sigstore's TUF repository there are 2 certificates:

• fulcio.crt.pem
• fulcio_v1.crt.pem

Keyless signatures produced some months ago have been signed with fulcio.crt.pem, while more recent ones have been signed with fulcio_v1.crt.pem.

Right now the cosign::Client uses just one certificate, which causes some signatures to fail verification.

Apparently the cosign client isn't affected by this issue. We should understand how the upstream client handles that, and replicate the behaviour here.

This is a draft pull request, but I would really appreciate getting some feedback.

Signed-off-by: jyotsna-penumaka [email protected]

Summary

Ticket Link

Fixes

Release Note

Quick question about our rekor submodule... a lot of the files (example here) have a header stating they are generated by OpenAPI, meaning they should not be edited manually. But I don't see any .yaml files included at all. Are we meant to have an openapi.yaml file somewhere to do this? Or are we intending to edit these files manually, and the header was left in by mistake?

Signed-off-by: Daniel Bevenius [email protected]

Summary

This commit suggests changing the tag used in EcdsaKeys::private_key_to_encrypted_pem from SIGSTORE_PRIVATE_KEY_PEM_LABEL to COSIGN_PRIVATE_KEY_PEM_LABEL.

The motivation for this is that using such a key with Go cosign will currently result in an unsupported pem type error. It seems like Go cosign is using CosignPrivateKeyPemType when checking the tag of the pem.

I'm not sure about the differences between SIGSTORE_PRIVATE_KEY_PEM_LABEL and COSIGN_PRIVATE_KEY_PEM_LABEL and I might be missing something here but if the change in this PR is a valid then this should probably be done for rsa and ed25519 as well.

Release Note

NONE

Documentation

NONE

I added exceptions to instances of unwrap that have a comment justifying use.

We now need to either toggle the last to handling the Option / Result or use except.

Test uses of unwrap will be ignored (as will examples)

Blocks unsafe

Signed-off-by: Luke Hinds [email protected]

Fixes https://github.com/sigstore/sigstore-rs/issues/131

Summary

Creates an async Fulcio client to make working with Fulcio more straightfoward.

Release Note

• Fulcio client for exchanging public key for signed certificate added.

Documentation

Rust docs provided.

Updates the requirements on xsalsa20poly1305 to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello sigstore-rs devs!

Description

This is a tracking issue for conformance testing between this client implementation and other Sigstore clients, similar to https://github.com/sigstore/sigstore-java/issues/236 and https://github.com/sigstore/sigstore-python/issues/297.

The rough idea here:

• Implement a small "driver" for this Sigstore client, one that adheres to the CLI protocol for the conformance suite
• Add a new conformance.yml workflow that applies the trailofbits/sigstore-conformance action via the driver

@tetsuo-cpp and I are happy to take a stab at the work here, whenever you feel it's appropriate!

cc @di

I'm interested in package signing support in crates.io + cargo using Sigstore. After looking through some of the earlier discussions from @lukehinds and others, it seems to me that the main obstacle is that crates.io and cargo teams have little time to work on this and/or review. In order to push things forward, I'm exploring an approach that could be used as basis for an RFC, with little changes to the existing crates.io and cargo code bases to reduce friction in adding the support and migrating existing infrastructure.

One of the things I've found is that cargo currently uses the curl (+ curl-sys) crate for HTTP, and does not support async Rust. I think it's going to be hard to justify changing a big chunk of cargo dependencies for this, so I'd like to hear others think.

Could it make sense to modify the fulcio and rekor clients, or alternatively create a set of clients with a lower level API, that could be re-used in places like cargo?

Here is the issue to align how models in the various repos are generated: https://github.com/sigstore/protobuf-specs/issues/3 Also, more detailed discussion here.

Description

The Fulcio V1 API will be turned down in the coming months.

https://github.com/sigstore/sigstore-rs/blob/main/src/fulcio/mod.rs#L20 will need to be updated to https://github.com/sigstore/fulcio/blob/main/fulcio.proto#L65. Fulcio V2 supports either gRPC or HTTP.

Description

In the next root-signing, we'll be migrating targets for fulcio under a fulcio subdirectory, and rekor under a rekor subdirectory (and keeping old targets for compatibility before we remove them).

This change was due to the fact that we had created delegations that were allowed to sign off on any path, but we actually only intend on certain delegations to add/update targets for a certain usage type (e.g. a delegation managing rekor rotations should only sign on the rekor/** space).

When we do this, fulcio targets will now be found on fulcio/* and rekor targets will be found on rekor/*. This may simplify some of the expressions for target matching SIGSTORE_FULCIO_CERT_TARGET_REGEX and SIGSTORE_REKOR_PUB_KEY_TARGET, since now their regex are simply fulcio/* or rekor/*. Old clients may continue to use this for a few months, given that we will continue supporting the top-level targets at their given paths, but we'd like clients to start moving towards retrieving fulcio certs by retrieving all targets under fulcio/*.

A few questions:

1. Does this targets() func retrieve delegated targets? Or just top-level targets? One way to find out is if you find a revocation.list returned in the current root. That is a delegated target not listed in the top-level targets.
2. When we totally remove the top-level original paths (rekor.pub and fulcio*.crt.pem) in favor of nesting them under subdirectories, will you need to continue to support old clients?