What container / envelope format should we use?

[mschwaig]

Right now we are using JSON/JWS, but in theory I would be open to the idea of switching to a different format.
I am writing down some of my thinking here to encourage an open debate about this.

The most important property which I want it that it should be an 'open' format, which allows for adding extra attributes without requiring prior coordination. I think this is critical for enabling the ecosystem to evolve.

It would also be good to keep signature verification, and everything else we can control about verification in accordance with some trust model able to run on constrained hardware, like HSMs, or as part of some verification that happens early during boot.

[mschwaig]

We could stick with JWS, or JWS while also using Canonical JSON (RFC 8785).

JSON would probably not be too inefficient over the wire via HTTP with a good transfer encoding.

A storage backend that can do some computation could be even more efficient by either

• compressing with zstd using a custom dictionary
• if we constrain ourselves to using Canonical JSON (RFC 8785), which might be a good idea, transform signatures into an even more efficient representation.

Such storage formats would not have to be specified or coordinated.

The downside of JWS is that it has quite a few implementation pitfalls, especially if you lean into the flexibility too much. OTOH algorithmic flexibility in general is a good goal to pursue for a signature format.
For sure implementations should make the flexibility of JWS not user-facing, but lock all of that down to some reasonable set of options they support. In the beginning probably one, to carry forward the current key format nix uses.

[mschwaig]

Another option I have not looked at too closely yet is CBOR (RFC 7049). It has a deterministic encoding as well (RFC 8949). There is also a JWS analogue, COSE.

It should be a bit better to handle in constrained environments than JSON.

FIDO Alliance uses it for https://fidoalliance.org/wp-content/uploads/2024/06/EDWG_Attestation-White-Paper_2024-1.pdf as far as I can tell (I think that's the reference @numinit gave me), and https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html.

[mschwaig]

Another option hat came up in the discussion with people from the snix project was ASN.1. Specifically the ability to set a criticality to force consumers to decline things they don't understand came up: http://obj-sys.com/asn1tutorial/tables.html
Also its suitability for constrained environments. That it is already an established format in relevant places might also play a role.

Philosophically I like decoupling builder and verifier better than the builder telling the verifier what to reject, but I came up with a specific application where it might be required to tell consumers to ignore a signature if they don't understand some specific data:

If you want to relax the sandbox, for example by giving it access to the GPU, this could be done somewhat securely, but it would in any case introduce a dependency on a whole host of things that need to be considered and audited, so if a signature is produced for a derivation which accesses a GPU at all, a verifier unaware of this tradeoff and extra verification work it has to do should reject that signature. A criticality flag would be useful for this use case.

Similar functionality can also be achieved in JSON or CBOR by mandating clients to fail verification if there is a value in the builder.crit section of a signature that they don't know about.

[mschwaig]

Another option that I still want to look into is https://github.com/secure-systems-lab/dsse.

in-toto adopting it is one fact that makes it look very interesting.