Add initial draft of specification based on ITE-5 #2
Conversation
Signed-off-by: Aditya Sirish <aditya@saky.in>
|
I've copied over ITE-5 and related resources here verbatim, it serves as a good starting point for us. Any thoughts on the best way to proceed? cc @SantiagoTorres @mnm678 @lukpueh @joshuagl @trishankatdatadog |
| - Parse SERIALIZED_BODY according to PAYLOAD_TYPE. Reject if the parsing | ||
| fails. | ||
|
|
||
| Either standard or URL-safe base64 encodings are allowed. Signers may use |
There was a problem hiding this comment.
Is there a good reason to allow for this flexibility? Why not just use the URL-safe one?
There was a problem hiding this comment.
Sorry for the late response. I've been in contact with different integrators and some of them use the non-url-safe version of b64. I wonder if this is something we can revisit on future iterations though.
There was a problem hiding this comment.
The reason for supporting both is that it makes it easier to produce signatures, at the small cost in complexity for consuming. In particular, protocol buffers produce standard encoding when converted to JSON, so it would be inconvenient if only URL-safe were supported. Since there will likely be only a handful of libraries to consume signatures, I thought this shift in complexity might be warranted.
|
Thanks for the review, @trishankatdatadog, I'm going to try and resolve them shortly. cc @mnm678 @lukpueh @SantiagoTorres @trishankatdatadog: How do you all feel about merging this PR in as version 0.1? The idea is to then update the ITE-5 PR to become a proposal to use signing-spec over the current document format. |
Signed-off-by: Aditya Sirish <aditya@saky.in>
Provided my comments are reviewed, I have no strong objections. |
|
I feel that we could get away with merging provided we solve the URI element to backwards-compatible json. I propose something like:
Or such. |
Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
specification.md
Outdated
| ``` | ||
|
|
||
| The PAYLOAD_TYPE is a URI indicating how to interpret SERIALIZED_BODY. It | ||
| encompasses the content type (JSON, CBOR, etc.), the purpose, and the schema |
There was a problem hiding this comment.
Should we recommend a canonical content type ? In one of our first discussions about this proposal we agreed that producing the signature over the canonical form has advantages, i.e. it makes signatures reproducible.
There was a problem hiding this comment.
💯
I'd like to start off this draft as backwards-compatible as possible. We cannot simply break existing clients unless we put this in the next major versions of tuf and in-toto...
There was a problem hiding this comment.
I've added Canonical-JSON to the list of options, rather than replace JSON. I wonder if the spec is best served by not taking a stance requiring canonicalization, while we as implementers for in-toto / TUF can use it to get benefits like reproducible signatures. As for backwards compatibility, the document has workflows for it which use canonical JSON for the current document formats. For new documents, the spec is not taking a stance against canonical JSON, it's merely not requiring it. Does that work? :)
|
So far we don't say anything about public key formats. I was hoping to resolve the issues that we have been brainstorming in secure-systems-lab/securesystemslib#251 and define supported key formats as part of this specification. Or should they go in a separate document, or be implementation specific? |
Great point. Let's put it in draft 2? 🙂 |
There was a problem hiding this comment.
Thanks for keeping this moving along @adityasaky, this looks reasonable to me as a starting point.
specification.md
Outdated
| ``` | ||
|
|
||
| The PAYLOAD_TYPE is a URI indicating how to interpret SERIALIZED_BODY. It | ||
| encompasses the content type (JSON, CBOR, etc.), the purpose, and the schema |
There was a problem hiding this comment.
| encompasses the content type (JSON, CBOR, etc.), the purpose, and the schema | |
| encompasses the content type (Canonical-JSON, CBOR, etc.), the purpose, and the schema |
I don't think we want to suggest using this signing scheme over non-canonicalised JSON?
There was a problem hiding this comment.
I've added Canonical JSON to the list rather than replace JSON and I think the in-toto and TUF teams can continue using canonical JSON for things like reproducible signatures. The spec doesn't mandate canonicalization here, but leaves it up to the implementers. Does that sound good? :)
FYI, Lukas brought up the same point here: #2 (comment)
- fix references - fix sentences - remove empty sections - fix header section Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
This is an initial draft of the specification based on the recommendations by @MarkLodato in in-toto/ITE#13.
Relevant to the discussions in #1 too.