We need to add an additional field on each signature that allows us to embed signature of that signature from permitted time stamping authorities.
Word soup, I know.
Basically we need to send a signature we generate of the in-toto link metadata to some time stamping authority to ensure we're creating signatures within a key's valid lifetime. It may look something like:
The shape of the timestamp object could differ based upon which standard was used to generate the timestamp. For instance RFC3161, X9.95, ISO/IEC 18014. See the below link for example.
Similarly the layout will need an additional field of trusted timestamp authorities' public keys. This may look similar to the existing "keys" field in the layout.
At verification time we will want to test each of the timestamps to ensure the key was valid when it was used to create the signature and ensure we trust the TSA used as defined by the layout.
At in-toto run time we need to take in a list of TSAs to use to generate timestamps for any signatures generated. This is tricky as not all timestamp specifications define transport methods. Currently I think we can just take in http endpoints that we can post a TSQ to, similar to how freetsa.org works: https://www.freetsa.org/index_en.php
In cases where a signature does not have any timestamps associated with it we will want to maintain the current in-toto behavior and only consider it valid if the signing key is valid at time of verification.
We'll want to start drafting an ITE for this functionality to build upon our work here. This should be separate from ITE7 so we can introduce this incrementally.
We need to add an additional field on each signature that allows us to embed signature of that signature from permitted time stamping authorities.
Word soup, I know.
Basically we need to send a signature we generate of the in-toto link metadata to some time stamping authority to ensure we're creating signatures within a key's valid lifetime. It may look something like:
The shape of the timestamp object could differ based upon which standard was used to generate the timestamp. For instance RFC3161, X9.95, ISO/IEC 18014. See the below link for example.
https://en.wikipedia.org/wiki/Trusted_timestamping
Similarly the layout will need an additional field of trusted timestamp authorities' public keys. This may look similar to the existing "keys" field in the layout.
At verification time we will want to test each of the timestamps to ensure the key was valid when it was used to create the signature and ensure we trust the TSA used as defined by the layout.
At
in-toto run
time we need to take in a list of TSAs to use to generate timestamps for any signatures generated. This is tricky as not all timestamp specifications define transport methods. Currently I think we can just take in http endpoints that we can post a TSQ to, similar to how freetsa.org works: https://www.freetsa.org/index_en.phpIn cases where a signature does not have any timestamps associated with it we will want to maintain the current in-toto behavior and only consider it valid if the signing key is valid at time of verification.