COSE receipt verification in C++ API #7494
Conversation
maxtropets
force-pushed
the
f/cose-receipts-verify-api
branch
2 times, most recently
from
744b727 to
9698e57
Compare
maxtropets
force-pushed
the
f/cose-receipts-verify-api
branch
from
9698e57 to
d7223d4
Compare
maxtropets
changed the title
There was a problem hiding this comment.
Pull request overview
This PR adds C++ APIs for decoding and verifying COSE-formatted CCF receipts. It introduces a private unified C++ API for decoding receipts and a public API to verify receipts against the current service identity.
Key Changes:
- New
decode_ccf_receipt()function for parsing COSE receipts with Merkle proof validation - New public
verify_cose_receipt()API for signature verification against network identity - Extended end-to-end tests to verify receipts and validate CDDL compliance for all proofs
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/node/cose_common.h | Implements COSE receipt decoding with Merkle proof parsing and root recomputation |
| src/node/historical_queries_utils.cpp | Implements public verification API using decoded receipts |
| src/node/node_state.h | Updates to use new decoding API instead of extracting issuer/subject directly |
| include/ccf/historical_queries_utils.h | Exposes public verify_cose_receipt() API |
| samples/apps/logging/logging.cpp | Adds /log/public/verify_cose_receipt endpoint |
| tests/e2e_logging.py | Extends test to verify COSE receipts with positive and negative test cases |
| src/crypto/test/cose.cpp | Adds unit test for receipt decoding |
| doc/schemas/app_openapi.json | Adds OpenAPI schema for new endpoint |
| CHANGELOG.md | Documents the new API |
maxtropets
force-pushed
the
f/cose-receipts-verify-api
branch
from
d7223d4 to
2f13c2f
Compare
| } | ||
|
|
||
| // Verifies CCF COSE receipt using the *current network* identity's | ||
| // certificate. |
There was a problem hiding this comment.
Is it always the current one, or any historical identity used by this ledger? Because I think we want the latter for self-transparency: it's ok to use artifacts made transparent on a previous incantation of the same service pre-DR.
There was a problem hiding this comment.
I'll rename it at this stage, passing roots of trust is only possible after preloading of such is done, then we can change the API at no cost, as it's probably going to be another dev-release.
| network_identity_subsystem) | ||
| { | ||
| auto receipt = | ||
| cose::decode_ccf_receipt(cose_receipt, /* recompute_root */ true); |
There was a problem hiding this comment.
Do we sometimes want to not recompute the root? When?
There was a problem hiding this comment.
When we don't verify it: https://github.com/microsoft/CCF/blob/main/src/node/node_state.h#L1146
| return proofs; | ||
| } | ||
|
|
||
| static CcfCoseReceipt decode_ccf_receipt( |
There was a problem hiding this comment.
I think we should have different return types with and without the root, to avoid accidents.
ReceiptWithRoot vs Receipt, and I would even have a separate decode_ccf_receipt_and_recompute_root() to be extra clear.
There was a problem hiding this comment.
I'd agree if it was external API, but it's not. User can always decode with recomputed root but ignore it afterwards, so can you elaborate what's the benefit?
Co-authored-by: Copilot <[email protected]>
3 participants
Two items of #7401.
This adds
Hence