feat: Move verify_trust into c2pa_crypto

[scouten-adobe]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 63.48921% with 203 lines in your changes missing coverage. Please review.

Project coverage is 80.85%. Comparing base (259a212) to head (30da87b).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/crypto/src/cose/certificate_profile.rs	49.85%	178 Missing ⚠️
sdk/src/cose_validator.rs	63.88%	13 Missing ⚠️
sdk/src/utils/test.rs	0.00%	4 Missing ⚠️
...ternal/crypto/src/cose/certificate_trust_policy.rs	95.31%	3 Missing ⚠️
...rnal/crypto/src/openssl/check_certificate_trust.rs	91.17%	3 Missing ⚠️
sdk/src/store.rs	88.23%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #784      +/-   ##
==========================================
- Coverage   81.05%   80.85%   -0.20%     
==========================================
  Files         114      115       +1     
  Lines       30989    30940      -49     
==========================================
- Hits        25117    25017     -100     
- Misses       5872     5923      +51     

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

[scouten-adobe]

This is the function formerly known as check_cert in cose_validator.rs.

[scouten-adobe]

These test fixtures were regenerated to match what was in the c2pa-rs test fixture directory.

In a prior PR, I had generated new ps*** certs and private keys, but that turned out to be unnecessary.

[scouten-adobe]

May not be relevant since we do this in check_certificate_profile above,

[mauricefisher64]

I think we can remove this comment since we check signing cert in cose_sign

[scouten-adobe]

‼️

[scouten-adobe]

Moved into c2pa_crypto crate above.

[scouten-adobe]

There are probably more error codes I could remove. Will do that in a subsequent PR.

[scouten-adobe]

@mauricefisher64 check this one especially. Is there something special about openssl's implementation of rand_bytes that we'd want to preserve? LMK and I'll adapt if so.

[mauricefisher64]

The only requirement is it should be a cryptographically random number generator.

[scouten-adobe]

Fixes #663

[mauricefisher64]

Looks like you removed this behavior:

// check the cert against the allowed list first
let cert_sha256 = hash_sha256(ee_der);
let cert_hash_base64 = base64::encode(&cert_sha256);
if th.get_allowed_list().contains(&cert_hash_base64) {
return Ok(true);
}
This was an optimization we use for the Verify site. Verify only stores the hashes of the der encoded pems. That greatly reduced the size of the payload and speed of lookup that Verify performs.

[mauricefisher64]

Same thing in the wasm case.

[scouten-adobe]

Ah, I wasn't aware of that use case, but I'll add it back.

[mauricefisher64]

If you look at load_allowed_list in the old versions you will see we allow you to use either PEM or DER hashes. Verify uses DER hashes.

[mauricefisher64]

Note this code should go away one day when we stop supporting end-entity certs.

[scouten-adobe]

Actually, if I read this right, we were already using DERs under the hood here. Which means Verify should be fine. And makes sense since the underlying API only accepts DER-encoded end-entity certs.

So I think this is OK as is. (Happy to change after merging if that's wrong.)

[mauricefisher64]

This is needed since this function could validate C2PA signatures (P1363) or those from certificates which are ASN.1 DER. I don't know if the new code is only used for DER now.

[scouten-adobe]

Typo: has should be hash

[scouten-adobe]

Will fix after meeting

[mauricefisher64]

Looks good