Summary
OcspResponse::from_der_checked (sdk/src/crypto/ocsp/mod.rs, main @ d15b8ee) returns OcspResponse::default() — i.e. "no usable OCSP information" — whenever the BasicOCSPResponse carries no certs field:
if let Some(ocsp_certs) = &basic_response.certs {
...
} else {
// we cannot validate the OCSP response signature, so treat as unknown
return Ok(OcspResponse::default());
}RFC 6960 §4.2.2.2 lists three kinds of authorized responder; the first is "the CA who issued the certificate in question", and such a response is signed with the CA's own key and typically embeds no certs at all (the client already holds the CA certificate as the leaf's issuer). RFC 6960 §2.2 likewise says the response "MUST be digitally signed" by the CA, a Trusted Responder, or a CA Designated Responder. So a CA-signed stapled response is currently discarded although its signature could be verified against the issuer certificate that is already in the signer's x5chain (or, since #2608, resolved from the trust anchors).
Reproducer (your own fixture)
sdk/tests/fixtures/ocsp.jpg carries two manifests, both with an rVals header. The ingredient manifest (signer CN=Adobe Firefly C2PA Stage, issuer CN=Adobe Product Services G4) staples exactly this form:
$ openssl ocsp -respin <rVals[0] of the ingredient manifest> -resp_text -noverify
Responder Id: D0AD428AF07A140725C697C043A82385E8B52D23 # = SKI / SHA-1 key hash of Adobe Product Services G4
Produced At: Aug 12 18:26:13 2025 GMT
Cert Status: good
This Update: Aug 12 18:26:13 2025 GMT
Next Update: Aug 19 18:26:13 2025 GMT
Signature Algorithm: sha256WithRSAEncryption
(no certificates)
The response verifies under the G4 certificate's public key and its CertID matches the leaf (SHA-1 of the leaf's issuer Name DER and of the G4 subjectPublicKey, serial 366ABE…A2AC). The active manifest's response, by contrast, embeds a CA-designated responder certificate and is handled.
Suggested behaviour
When certs is absent (or none of its entries matches the ResponderID), treat the leaf's issuing CA as the candidate responder: match ResponderID byName against the issuer's subject or byKey against SHA-1(issuer subjectPublicKey bits), verify the response signature with the issuer's SPKI, and proceed to the CertID and time checks as today. This is the §4.2.2.2 case-1 path; #2468 and #2608 already make the issuer certificate available.
Context
Found while cross-checking an independent C2PA 2.4 validator (lintology c2pa_core::revocation) against this fixture; happy to test a patch against it.
Summary
OcspResponse::from_der_checked(sdk/src/crypto/ocsp/mod.rs, main @ d15b8ee) returnsOcspResponse::default()— i.e. "no usable OCSP information" — whenever theBasicOCSPResponsecarries nocertsfield:RFC 6960 §4.2.2.2 lists three kinds of authorized responder; the first is "the CA who issued the certificate in question", and such a response is signed with the CA's own key and typically embeds no
certsat all (the client already holds the CA certificate as the leaf's issuer). RFC 6960 §2.2 likewise says the response "MUST be digitally signed" by the CA, a Trusted Responder, or a CA Designated Responder. So a CA-signed stapled response is currently discarded although its signature could be verified against the issuer certificate that is already in the signer'sx5chain(or, since #2608, resolved from the trust anchors).Reproducer (your own fixture)
sdk/tests/fixtures/ocsp.jpgcarries two manifests, both with anrValsheader. The ingredient manifest (signerCN=Adobe Firefly C2PA Stage, issuerCN=Adobe Product Services G4) staples exactly this form:The response verifies under the G4 certificate's public key and its
CertIDmatches the leaf (SHA-1 of the leaf's issuer Name DER and of the G4subjectPublicKey, serial366ABE…A2AC). The active manifest's response, by contrast, embeds a CA-designated responder certificate and is handled.Suggested behaviour
When
certsis absent (or none of its entries matches theResponderID), treat the leaf's issuing CA as the candidate responder: matchResponderIDbyName against the issuer's subject or byKey against SHA-1(issuersubjectPublicKeybits), verify the response signature with the issuer's SPKI, and proceed to the CertID and time checks as today. This is the §4.2.2.2 case-1 path; #2468 and #2608 already make the issuer certificate available.Context
Found while cross-checking an independent C2PA 2.4 validator (lintology
c2pa_core::revocation) against this fixture; happy to test a patch against it.