in-toto
ITE-12: CDDL, CBOR, and COSE signatures
I'd like for us to attempt to tackle the conciseness problem with an internet standard wire format with associated data definition language.
With CDDL defining the structure of all the predicates precisely, we can see about adding in-toto as a Tag type in the IETF CoRIM specification.
Hi @deeglaze, sorry for the delay!
We've had earlier attempts at not being very specific about serialization formats and signing envelopes. I wonder if a subset of what you propose here can be applied to the in-toto/attestation spec so that spec is not JSON-specific. We already have ITE-5 that'll allow for using COSE.
At that point, would it require some operational pieces in in-toto/attestation to enable CDDL (i.e., if the spec is updated to be less dependent on JSON alone)?
cc @in-toto/attestation-maintainers
My b, I had an action item on this and never got to it. I claim that writing an informational ITE should be doable, so that we have an "encoding" of how the COSE wrapper should be implemented. In theory the ITE-5 carveout lets implementers use COSE and be compliant/follow the spec, but we could add more clarification on e.g., what're authenticated headers on in-toto if you're using a COSE wrapper...
Agreed with an information ITE along the lines of the successful idea of Uptane-style protocols, operations, usage, and formats (POUFs).
The downside of the "we allow other serialization formats" but the project's own rejection of anything other than targets of protoc, which is entirely Google-controlled, makes ITE-5 weak without this proposal. If there were openness to contributions to a different serialization format that aren't supported by protoc, then I wouldn't mind. My intention was to get very specific data models specified even if they're still treated as an information model for different serialization in order to have unambiguous interpretation. I don't want to take an open source project, make a bespoke format for internal efficiency, and then not be able to contribute back for what we use to be more broadly understood in the same ecosystem.
Thanks for reaching out. I believe this is supported by the spec, but we'd like to make this more explicit. Right now, we were planning to make CBOR support clear first in the DSSE spec and then look to clarify things like this here. So, stay tuned!
On Wed, Nov 12, 2025 at 7:46 PM Dionna Amalie Glaze < @.***> wrote:
deeglaze left a comment (in-toto/ITE#60) https://github.com/in-toto/ITE/pull/60#issuecomment-3524564936
The downside of the "we allow other serialization formats" but the project's own rejection of anything other than targets of protoc, which is entirely Google-controlled, makes ITE-5 weak without this proposal. If there were openness to contributions to a different serialization format that aren't supported by protoc, then I wouldn't mind. My intention was to get very specific data models specified even if they're still treated as an information model for different serialization in order to have unambiguous interpretation. I don't want to take an open source project, make a bespoke format for internal efficiency, and then not be able to contribute back for what we use to be more broadly understood in the same ecosystem.
— Reply to this email directly, view it on GitHub https://github.com/in-toto/ITE/pull/60#issuecomment-3524564936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD2SBTQ6PWQI5JJLFDT34PIF5AVCNFSM6AAAAABZYDM2UWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRUGU3DIOJTGY . You are receiving this because your review was requested.Message ID: @.***>
