Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Move c2pa::CoseValidator to c2pa_crypto::RawSignatureValidator #683

Merged
merged 35 commits into from
Nov 19, 2024

Conversation

scouten-adobe
Copy link
Collaborator

No description provided.

@scouten-adobe scouten-adobe self-assigned this Nov 16, 2024
Copy link

codecov bot commented Nov 16, 2024

Codecov Report

Attention: Patch coverage is 77.81250% with 71 lines in your changes missing coverage. Please review.

Project coverage is 81.55%. Comparing base (f84c581) to head (df219df).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
sdk/src/time_stamp.rs 77.93% 32 Missing ⚠️
internal/crypto/src/raw_signature/validator.rs 31.81% 30 Missing ⚠️
internal/crypto/src/openssl/validators/mod.rs 80.00% 6 Missing ⚠️
sdk/src/cose_validator.rs 81.81% 2 Missing ⚠️
...l/crypto/src/openssl/validators/ecdsa_validator.rs 96.42% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #683      +/-   ##
==========================================
- Coverage   81.77%   81.55%   -0.22%     
==========================================
  Files         101      104       +3     
  Lines       30916    30602     -314     
==========================================
- Hits        25281    24958     -323     
- Misses       5635     5644       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


🚨 Try these New Features:

let s = BigNum::from_slice(&sig[sig_len..])?;
EcdsaSig::from_private_components(r, s)?.to_der()?
} else {
sig.to_vec()
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauricefisher64 do you know of a case where the signature is not encoded as P1363?

Copy link
Collaborator

@mauricefisher64 mauricefisher64 Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OpenSSL/AWS KMS/X509 certs use DER. Web standards and Cose/C2PA use P1363

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So when we sign with OpenSSL or we are checking certificates the values are DER.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauricefisher64 reason I'm asking is that the unit test framework isn't generating coverage for line 70 (the DER case) so I'm looking for sample data that would exercise that case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is you sign something with straight OpenSSL it will be a DER signature. You can't use a signature that came from Cose because it will be in the other format.

/// ECDSA with SHA-384
Es384,
// ECDSA with SHA-512
// Es512, // not yet implemented (check with Colin)
Copy link
Collaborator Author

@scouten-adobe scouten-adobe Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cdmurph32 why was Es512 not implemented in #653?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the switch to Rustls here is a regression. We currently support ES512 with SubtleCrypto.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, that's the reason to keep the async path open. SubtleCrypto requires async.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code path is synchronous-only.

@@ -29,53 +25,3 @@ pub struct ValidationInfo {
pub cert_chain: Vec<u8>, // certificate chain used to validate signature
pub revocation_status: Option<bool>,
}

/// Trait to support validating a signature against the provided data
pub(crate) trait CoseValidator {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced by c2pa_crypto::raw_signature::RawSignatureValidator.


/// return validator for supported C2PA algorithms
#[cfg(feature = "openssl")]
pub(crate) fn get_validator(alg: SigningAlg) -> Box<dyn CoseValidator> {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced by c2pa_crypto::raw_signature::validator::validator_for_signing_alg.

@@ -16,33 +16,16 @@ mod rsa_signer;
#[cfg(feature = "openssl_sign")]
pub(crate) use rsa_signer::RsaSigner;

#[cfg(feature = "openssl")]
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These all moved into c2pa_crypto::openssl::validators.

/// lacks an Eq implementation. Instead we capture the error description.
#[cfg(feature = "openssl")]
#[error("an error was reported by OpenSSL native code: {0}")]
OpenSslError(String),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a very good choice.

Copy link
Collaborator

@mauricefisher64 mauricefisher64 Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we allow the RawSignatureValidationError to return LogItem to get the detailed error info?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauricefisher64 the LogItem code was never plumbed down this far in the code being replaced. Certainly open to a subsequent PR that would add it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauricefisher64 I saw this error case a few times while debugging the new code and I was pretty pleased with the description that was provided. It included the OpenSSL file name and line number.

///
/// Which validators are available may vary depending on the platform and
/// which crate features were enabled.
pub fn validator_for_signing_alg(alg: SigningAlg) -> Option<Box<dyn RawSignatureValidator>> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to think about this. It may be too restrictive. There are cases where we validate patterns that don't match our predefined signature types. For example You can have an EC signature that uses an arbitrary hash length. They are not limited to for example ES256 where the sig is on curve prime256v1 but the hash is Sha256. You can use that curve with other hash values. We see this when validating certs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauricefisher64 this is pretty directly taken from existing code in validator.rs: https://github.com/contentauth/c2pa-rs/blob/main/sdk/src/validator.rs#L62-L75

There was a separate function get_local_validator that had more flexibility and I've carried that over as validator_for_sig_and_alg_oids a little farther down in this file.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. We will have to do some testing against those odd cert cases.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mauricefisher64 would love to have new test cases for anything else you're familiar with.

p256 = "0.13.2"
p384 = "0.13.0"
rsa = { version = "0.9.6", features = ["sha2"] }
spki = "0.7.3"
wasm-bindgen = "0.2.83"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wasm-bindgen, web-sys, web-time can not be included in the wasi target. I know this PR isn't really about adding WASI support, but there are other wasi targets in the Cargo.toml


const SAMPLE_DATA: &[u8] = b"some sample content to sign";

#[test]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With these changes I thought these unit tests would work for both WASM and non-WASM cases?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you're saying here. Next line flags it was a WASM-compatible test.

Unfortunately, the WASM test framework doesn't respect the standard #[test] annotation. 😢

match alg {
SigningAlg::Es256 => Some(Box::new(EcdsaValidator::Es256)),
SigningAlg::Es384 => Some(Box::new(EcdsaValidator::Es384)),
SigningAlg::Es512 => None, /* why is this unimplemented? */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting? This is implemented in the current c2pa-rs

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the synchronous case for WASM, it's not implemented. @cdmurph32 can you explain?

@scouten-adobe scouten-adobe merged commit 707e56d into main Nov 19, 2024
24 of 26 checks passed
@scouten-adobe scouten-adobe deleted the move-cose-validator branch November 19, 2024 17:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants