scitt-community / scitt-api-emulator

SCITT API Emulator

Home Page:https://scitt-community.github.io/scitt-api-emulator

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is that possible to use a file as payload?

skoll9903 opened this issue · comments

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.

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.

in the context of the emulator, the payload of a COSE Sign1 "signed statement" can be a file content, for example:

if ctyp is application/json the payload could be the bytes of example.json.

@skoll9903 this seems to have been answered and the functionality works. Can we close this issue or do you have more questions?

Hi Jon:
I am terribly sorry that I failed to respond to your emails, over and over again. I know it was really rude, and I felt ashamed for being an A-hole. I can’t expect for you guys to forgive me but I hope this can at least make you feel better. I do have some personal issue but it is not a excuse to be rude.

I was trying to work on SCITT at that moment, but not anymore now, I am glad to hear that functionality works, Congratulations. I will close that issue at once, hopefully it helps.

I apologise again if I made you and other team members unpleasant.

Regards