JAG-UK
commented
1 year ago Hi skoll9903,
disclaimer I am a maintainer of this project and co-chair of the IETF SCITT working group. I do not speak in either capacity here, but rather seek to give the most helpful answer I can personally give.
TL;DR: what you want is absolutely possible within the philosophy of SCITT, and is available in commercial products, but isn't yet in this implementation which is trying to track the evolution of the standard.
Of course you're very welcome and encouraged to join this Open Source community and/or the official IETF working group if this is a core interest to you.
Longer version: As you might observe the stats of the actual standard is still quite early and we're really trying with this emulator not to jump the gun on important design decisions that haven't been made in the IETF group yet.
One such important decision still under debate is how (or even whether!) to include the payload in the registry storage, and so for now in the emulator we have a quite simple approach to proving the main point of SCITT using strings or string dictionaries. With very large binaries we run into additional practical problems of storage scale and so on so techniques such as hashing, or IPFS storage or something deserve consideration.
Do bear in mind that transparency is fundamentally about EVIDENCE and ATTESTATIONS, and you don't necessarily need (or in some cases even want) to transport the main artefact with its integrity information. Splitting responsibility for the different jobs of confidential delivery, integrity validation, and authenticity can be much more powerful than bundling everything in one channel.
Lastly I would caution that this is, as it says, an emulator. It's not intended for production deployment right now. Commercial offerings do exist that do exactly what you want (including but not limited to one from the company I work for, https://rkvst.com and without bing able to make any promises on behalf of any commercial company it is hoped that many of these will fall into line with the SCITT standards as they develop.
johnandersen777
OR13
skoll9903
Hi letmaik: Thank you and all other contributors for your work on this project. Hope you don't mind if me provide some suggestions. In my understanding, the payload in this project is defined as a string variable now, which can be defined in command lines. Is that possible to use an actual file as a payload? (i.e. .json/.tar/.py files) I am currently trying to find a secured and transparency method to deliver security config files from manufacturers to consumer, without any malicious modification. And I believe the SCITT mechanism can help with this goal, for example, use these security config files as a payload. On the other hand, most of the software is delivered in binary executable files or source code files. And I believe that by allowing this emulator to support a file as payload would provide a better simulation for software distribution process. Thank you again for considering my immature thoughts.