What comes before v1.0?

[adityasaky]

With these requirements addressed in the current draft of the signing-spec, it's likely time to discuss what needs to be addressed before we're ready to tag v1.0. Achieving stability in the spec would enable us to work on the adoption in-spec in ITE-5 / TAP-TBD, and in-code via work on signing-spec implementations.

[adityasaky]

Tagging: @MarkLodato @SantiagoTorres @lukpueh @trishankatdatadog @mnm678 @joshuagl @JustinCappos

[adityasaky]

FYI: I just tagged v0.1.0 -- https://github.com/secure-systems-lab/signing-spec/releases/tag/v0.1.0

[trishankatdatadog]

Do we have working prototypes somewhere, especially one to support Google's use case, and another to support our Canonical JSON? That would be the only thing that would really convince me, not endless specifications.

[MarkLodato]

I suggest creating a GitHub milestone for this. (If you add me as an editor in the project, I'd be happy to set that up for you.)

I filed #28 for the reference implementation.

[adityasaky]

I've created the milestone and added #28 to it.

[dlorenc]

Do we have working prototypes somewhere, especially one to support Google's use case, and another to support our Canonical JSON? That would be the only thing that would really convince me, not endless specifications.

I don't know if this is a "reference" implementation, but we have "an" implementation here: https://github.com/in-toto/in-toto-golang/blob/master/pkg/ssl/sign.go

[MarkLodato]

I propose that the following are the only blockers:

• Choose a more specific name than "signing-spec" #16 Choose a more specific name than "signing-spec"
• Use a simpler PAE #27 Use a simpler PAE
• Create a reference implementation and test vectors #28 Create a reference implementation and test vectors

Once we have done these three, we tag it as 1.0. Any objections?

[TomHennen]

How much do were care about #27? There's already an implementation that uses the already defined PAE.

I'm fine either way, I just want to make sure this is actually a good use of time.

[MarkLodato]

IMO it's valuable since it significantly simplifies the implementation and is an easy change to make.

[TomHennen]

SGTM

[laurentsimon]

I chatted offline with @MarkLodato on the possibility to use a simpler encoding for the envelope part too: that would prevent recipients from using a full-blown json parser on untrusted input. But it's yet more work to make this change and may not best use of time at this stage.

[MarkLodato]

It's 1.0 now!