in-toto-golang
in-toto-golang copied to clipboard
in-toto
in-toto attestation JSON schema verify via CLI
Abstract
in-toto attestations are in the form of JSON. We can use JSON schema to validate the schema of the attestation.
Motivation
We started to work on a PR to verify in-toto attestations by using Cue or Rego languages in the cosign project. So, if in-toto attestations have JSON schemas, we can use them in the in-toto-golang CLI. Also, cosign has a dependency on the in-toto-golang project for the structs of the in-toto attestations. So, if we add support of verifying JSON schemas to the in-toto-golang project, we can use it in cosign project too.
References
I found some additional resources that might help us to implement this:
cc: @dentrax @erkanzileli
in-toto uses Canonical JSON which may complicate this effort. http://wiki.laptop.org/go/Canonical_JSON
is it a blocker thing, or do we figure this out somehow? @shibumi @colek42
Are Cue and JSON schemas canonical? If they are, I don't think this is a problem, right?
what do you mean by canonical? I really don't know how to respond that 🤷🏻♂️
@developer-guy Sorry, my bad. Let me rephrase it: are CUE and JSON Schema compatible with Canonical JSON? If I get this right:
Cue and JSON Schema provide a schema for cue or JSON. Then I am able to validate the CUE/JSON against the Schema. My question is: Can Cue or JSON Schema validate if the provided JSON for schema validation is Canonical JSON?
It is possible that my question is completely out of this discussion :D I am really not an expert in CUE or Canonical JSON.
sorry for the ping @verdverm but maybe you can help us here with @shibumi's question because I also don't know that. Btw, this topic is related to what we want to do in the PR for the cosign project.
From what I understand, Canonical JSON is a subset (restricted version) of JSON, though poorly named if you want my opinion ;]
Both CUE and JSON Schema should be able to handle this.
@verdverm I understood Canonical JSON as "ordered" JSON. Question is if cue would validate this correctly:
**NOTE: the following files are pseudo .. I have no idea if the syntax is right, but the idea behind it should be"
file 1
{
"test": "A",
"foo": 1,
}
file 2
{
"foo": 1,
"test": "A",
}
Template JSON Schema or CUE:
{
"foo": number,
"test": string,
}
With Canonical JSON only the file 2 should be approved by the template. The validation for file 1 MUST fail. With normal JSON this is not the case and a JSON Schema would validate both files successfully, iirc.
Ah, I missed that lexicographical part in their spec.
You could do this with CUE, though it would require some extra stuff. By default, CUE is intentionally order ignorant. You can probably use extra constraints (IsSorted on the object keys through a list comprehension)
You can probably use extra constraints (IsSorted on the object keys through a list comprehension)
I think the Canonical JSON spec is more complicated than this. They have weights on each type and so on...
We use Canonical JSON for ensuring the same hash for attestations (iirc).
Wouldn't generating attestations using DSSE help here? There's already some support for it...
I think the plan is to validate attestations via a schema, not to generate them. I might be wrong.
Yes, but we won't be using cjson if the attestations are in DSSE as I understand it.
Edit: so we can validate them using JSON schema as originally suggested?
FYI, started: https://github.com/cue-lang/cue/discussions/1285 (CUE and Canonical JSON)