If you are signing proprietary artifacts and you’ve decided you don’t want to use a transparency log - don’t worry - there are other solutions to verify an artifact’s signature trustworthiness. However, you should know that they lack transparency and auditability mechanisms in comparison with those provided by transparency logs.
TimeStamping Authority Services
One of these solutions consists of relying on a timestamping service to support assertions that a datum existed before a particular time. A timestamping authority (TSA) like the one defined in the RFC-3161 protocol works as a trusted third-party providing a "proof-of-existence" that the data existed at a particular moment in time. One of the common uses of a TSA is to verify that a digital signature was applied to a message before the corresponding certificate expired. This allows a public key certificate to be used for verifying signatures created prior to the time of expiration of the certificate. In other words, timestamps are used to verify short lived certificates. In this blog post, we focus on signing the artifact signature and therefore ensuring the signature was created at a certain time.
How does it work ?
A timestamping authority client requests a timestamp token from a TSA server which sends a signed response, as described in Figure 2.
Note that as specified in RFC-3161, TSA servers must sign each timestamp message using a public key infrastructure reserved specifically for that purpose. Once the client receives the signed response it uses the TSA server’s root public key to verify the signature. The client verifies that the timestamp response comes from the expected party, covers the provided data and has an up-to-date time.
How can I use it ?
Generally there are multiple publicly accessible TSA services such as Sectigo or DigiCert. We recommend using the Sigstore TimeStamping Authority for artifact’s signature signing. Sigstore has recently added support to cosign for the RFC-3161 protocol by using a Sigstore TSA compatible server. Chainguard provides a publicly accessible TSA instance (https://tsa.enforce.dev) based on Sigstore's TSA implementation.
In Figure 1, we describe a Sigstore artifact’s signing process using a TSA instance. First, users authenticate with an OIDC identity and get an OIDC token. Cosign generates an ephemeral public/private key pair. Then it sends the public key along with the OIDC token to issue a short-lived certificate which is published on a transparency log. Once we get the certificate, cosign signs the artifact and uses the signature to request a timestamped token from a TSA instance. Finally, cosign publishes the signed artifact including the timestamped token. When ensuring the trustworthiness of an artifact’s signature, cosign fetches the signature and verifies the signed timestamp.
To sign a container image using a TimeStamping Authority, you can use Sigstore cosign with the following command:
The “--timestamp-server-url” flag represents the url to the Timestamp RFC-3161 server to use.
To verify the signature on the container image, you can use the following command:
The “--timestamp-certificate-chain” flag defines the path to the root key material for the Timestamp Authority.
Remember that for cosign, we sign over the raw signature bytes. Signing over the signature ensures that the signature of the artifact was created at a particular point in time.
Enhance Security using TSAs
To improve the trustworthiness of a signed artifact, it is recommended to employ several TSA servers. Multiple timestamped tokens on the same artifact from different servers means you don’t have to put all your trust in a single TSA.
Another mechanism to enhance the security of the signed artifacts could be achieved by using additional verification mechanisms. You could use your own TSA and a Transparency Log. Sigstore allows using both verification mechanisms and consequently makes your own TSA instance to be part of the Sigstore trust chain. You could use Rekor and your TSA instance, as long as it is a Sigstore TSA server, to improve the proof-of-existence of a particular signature while Rekor offers auditability and transparency. In the following example, we use Cosign, Rekor and our own Chainguard’s TSA instance using the following flags:
To verify the signature on a container image using both Rekor and a Sigstore TSA server, you just need to run the following command:
Nowadays you could also enforce a TSA verification on a signed container image in Kubernetes. Sigstore policy-controller already supports TSA verification for signed images deployed on a Kubernetes cluster. In the Sigstore policy-controller, you can define a list of TSA servers to use when verifying a container image.
TSA instances could also improve the internal verification mechanisms of the existing Rekor entries. Timestamps are a critical component of Rekor. They are used to verify short-lived certificates. Currently, the timestamp added to any new Rekor entry comes from Rekor's own internal clock, which is not externally verifiable or immutable. Therefore, using signed timestamps issued by TSA instances mitigates the risk of Rekor's clock being manipulated.
Conclusion
If auditability and transparency aren’t what you are looking for in your organization, TSA instances represent a valid verification mechanism to ensure the integrity of your private signed artifacts. However, we recommend combining both TSA instances and TLog services to improve your security model. Finally, this blog outlines the benefits of bringing your own TSA instance and therefore being part of the trust chain.
