sigstore / timestamp-authority

RFC3161 Timestamp Authority

sigstore framework

sigstore/sigstore contains common Sigstore code: that is, code shared by infrastructure (e.g., Fulcio and Rekor) and Go language clients (e.g., Cosign and Gitsign).

This library currently provides:

• A signing interface (support for ecdsa, ed25519, rsa, DSSE (in-toto))
• OpenID Connect fulcio client code

The following KMS systems are available:

• AWS Key Management Service
• Azure Key Vault
• HashiCorp Vault
• Google Cloud Platform Key Management Service

For example code, look at the relevant test code for each main code file.

Fuzzing

The fuzzing tests are within https://github.com/sigstore/sigstore/tree/main/test/fuzz

Security

Should you discover any security issues, please refer to sigstores security process

For container signing, you want cosign

timestamp-authority's Issues

Refactor verification function with Opts struct

Description

Per RFC 3161 2.2, we need to support the following for verification:

• Verify that the TSR's hashed message matches the digest of the artifact to be timestamped
• Verify the TSR's ESSCertID, the certificate identifier, matches a provided TSA certificate (kind of done here, but see below for note on updating to support out-of-band provided leaf)
• Verify the leaf certificate's subject and/or subject alternative name matches a provided subject - See https://github.com/openssl/openssl/blob/master/crypto/ts/ts_rsp_verify.c#L536
• If embedded in the TSR, verify the TSR's leaf certificate matches a provided TSA certificate
• Verify the TSA certificate using a CA certificate chain
• Verify the TSA certificate and the intermediates (called "EKU chaining") all have the extended key usage set to only extended key usage - See https://github.com/sigstore/timestamp-authority/blob/main/pkg/x509/x509.go#L35 - Note that the pkcs7 library verify does not check this
• Verify the signature of the TSR using the public key in the leaf certificate (like here)
• Verify the OID of the TSR matches an expected OID
• Verify the status of the TSR does not contain an error
• Verify the nonce - Mostly important for when the response is first returned

Note that the leaf certificate may be provided out of band, as it is not a requirement that the certificate is embedded in the TSR. verifySignature from the pkcs7 library seems to expect that the certificate is present always. We'll need upstream changes I think to update verification to support TSRs without certificates.

It looks like there are more errors in the pkcs7 verification logic - for example, https://github.com/digitorus/pkcs7/blob/21b8b40e6bb42e43036336c7828a1bee77c2b1d6/verify.go#L157 assumes that all certificates stored in the pkcs7 certs struct are intermediates (so I don't think verification even works if you have a chain with an intermediate? Haven't confirmed though, please do). Upstream fixes are probably needed. I'd avoid reimplementing signature verification (complex!, so let's try to fix in upstream, and we can work off my fork for now.
EDIT: Verification works in our code because we read in all certificates into a single cert pool, and those are called the "trust store" roots - Since the leaf is in this cert pool, and the leaf is in the p7.Certificates, then verification passes because it'll find a "chain" from leaf to leaf. This is ok to use as long as we also verify the certificate chain ourselves, but I think it's worth still figuring out how to redesign this in upstream. Something like VerifyWithChain here taking a root pool, intermediate pool, optional leaf certificate, and optional EKU.

The Opts pattern we've followed from Cosign has worked well, so I'd recommend we do the same here.

type VerificationOpts struct {
  oid asn1.ObjectIdentifier
  TsaCertificate *x509.Certificate
  Intermediates *x509.CertPool
  Roots *x509.CertPool
  Nonce string
  Subject string
}

Blocked by #119

@malancas did you want to take a look at this?

Add http2 support

Description

The server should be able to receive both http2 and http1 requests.

Unit test for CLI requires binary

Description

If the binary hasn't been rebuilt recently, then this can cause test errors. Two ideas:

• Tag these tests as e2e and provide instructions for what to do before running e2e tests (make timestamp-cli)
• Build the CLI while running the test - if we do this, we should build it in a temporary folder and clean up after the test finishes. I kind of prefer this, as I'd rather not have e2e tagged tests if we can avoid them

What payload should we send to the TSA in Sigstore?

Is it going to be the same thing we send to Rekor? Something simpler?

I think I've heard folks chatting about this and maybe there are docs around but would love a place to centralize discussion.

Add documentation

• How to operate TSA
• How to generate timestamp requests and verify with openssl (custom tooling too for verifying cert chain?)
• Threat model

Review codebase

Description

There's a lot of code that's been copied over. We should review if there's anything that's no longer needed. Also best practices for go services.

[Docs] Update the policy with respect to timing accuracy

The listed policy today states:

Section 7.3.1#4:

        The time included in the time-stamp token shall be
        synchronized with UTC within the accuracy defined in this
        policy and, if present, within the accuracy defined in the
        time-stamp token itself;

And in 7.3.1#5:

        If the time-stamp provider's clock is detected (see section
        7.3.2c) as being out of the stated accuracy (see section
        7.1.2e)) then time-stamp tokens shall not be issued.

Those two statements are not correct. The accuracy is hard-coded ant not listed in the policy document, and the TSA does not stop issuing time-stamp tokens if a clock drift is detected.

Suggested change for 7.3.1#4

The time-stamp provider should periodically monitor it's correctness of time with a set of trusted UTC sources. 
The recored accuracy should be recorded into the returned time-stamp token.

Loosely we can rewrite 7.3.1#5 (@haydentherapper 's suggestion):

The time-stamp provider SHOULD monitor for accuracy and alert if it's found to be out of sync

Choose timestamp signer

In-memory backed by KMS (by Tink) is my preference.

Other option would be KMS.

Upload TSA code from Rekor repository

Could we release a container image?

Description

In order to bring in this to scaffolding:
sigstore/scaffolding#450

And I'd expect that others would like a container also at some point, so it would be nice to get a container image released for this. I can work around this for now, but would be nice to get a released container.

Integrate project into oss-fuzz

Description

We can leverage oss-fuzz to run nightly fuzzing tests. I think this may uncover issues in the pkcs7 library rather than this repo, as this mostly just calls out to other libraries.

We'd need to follow this guide to onboarding the project, following a template like rekor.

Signer hardcodes use of SHA-256

Description

When a new crypto signer is created, the hash function is hardcoded to SHA-256. This can be found on the following lines:

• timestamp-authority/pkg/signer/signer.go

  Line 47 in 4121517

  signer, err := kms.Get(ctx, kmsKey, crypto.SHA256)

• timestamp-authority/pkg/signer/signer.go

  Line 42 in 4121517

  sv, _, err := signature.NewECDSASignerVerifier(elliptic.P256(), rand.Reader, crypto.SHA256)

The signer should accept a hash function configured when the server is created.

Version

Add monitoring

Adding malancas as maintainer

Description

Meredith (@malancas) has done a lot of work on the timestamp authority, completing a number of P0/P1 AIs to get a first release out, and driving the implementation of the verification library. Meredith has helped to review many PRs in this repo too. I'd like to propose Meredith as a maintainer for the repo.

cc @asraa for approval for other maintainers

Review release tooling

• Do we need the OIDC setup tooling?
• Review release.mk and Makefile

Set up branch protections

Define timestamp granularity

Integrating with a NTP server

Description

We should investigate the possibility of integrating the TSA with a NTP server. CloudFlare offers a free NTP server as a possible option (credit to @haydentherapper for finding this). GCP also offers NTP integration for its VMs.

In addition to providing a NTP server, the CloudFlare article also discusses an updated protocol based on NTP called NTS to communicate with the server. However, there does not seem to be Go support for the NTS protocol. There seem to be a few Go implementations of the NTP protocol on GitHub.

Create Helm chart for deploying

Description

Update in memory signer to use an intermediate

Description

This will better reflect the production environment and catch any verification issues.

Move fetch_ca_certs to its own module to be separate from the server

Description

[timestamp-server] Serving over HTTPS is not configurable

Description

It seems the server code supports the usage of https, but it is currently hardcoded to use http, https://github.com/sigstore/timestamp-authority/blob/main/cmd/timestamp-server/app/serve.go#L66. In addition, I found many of the cobra flags weren't bound to the viper flags. To figure it out, I passed flags --scheme to the server but that one was not bound to the viper flags.

I'm also wondering whether it makes sense to have HTTPS support for the TSA.

Update verify CLI to separate roots/intermediates/leaf

Description

Similar to OpenSSL, we need to differentiate between untrusted intermediates/leafs and trusted roots.

Blocked by verification refactoring

Update pkcs7/timestamp dependencies

Description

Currently using personal fork.

Blocked by digitorus/pkcs7#8

Integrate with Sigstore Swagger docs

Description

Figure out how to get our swagger output into https://www.sigstore.dev/swagger/

Limit who can cut releases

Description

Currently, any time a tag is pushed, a release is cut. We need to review who has permission to push a tag (anyone with write or maintain? Or does it include triage?) and possibly restrict the list.

Implement a mock client

Description

We need to create a mock client where all the different API calls are supported and these functions return valid data for testing purposes.

Add .github CI scripts

Missing release cutting, validating release, scorecard, build, codeql. Copy from Rekor

Move repo to sigstore org

Description

Improve timestamp-cli

Description

• Review the output
• Review the input params
• Make sure there's no leftovers from Rekor
• Add timestamp verification into CLI

Clean up duplicated flags

Description

• hostname is unused
• address is the same as the openapi provided host flag
• port is duplicated
• read and write timeouts should be set by read-timeout/write-timeout for pprof/metrics

Default to NTP monitoring being on

Description

I think this is a useful feature and we should change the flag to default to using the provided ntp monitor configuration.

cc @kommendorkapten

Add Recoverer middleware

Description

https://github.com/go-chi/chi/blob/master/middleware/recoverer.go

Also review other middleware that's currently enabled

E2E test for issuing response

Description

Make the verification logic reusable by other projects

Description

I'd like to reuse the verify logic in other projects. At the moment, this implementation is private, consuming viper flags and it's located under the cli/cmd packages. Perhaps we could move it under pkg directories and split the cli logic from the verify logic itself. Any thoughts ?

Reject requests that uses SHA-1.

Description

• RFC 5816 suggests an update to RFC 3161 by utilizing ESSCertIDv2 for signer certificate, beyond SHA-1:

The time-stamping protocol defined in RFC 3161 [RFC3161] requires
that the Cryptographic Message Syntax (CMS) SignedData [RFC5652],
used to apply a digital signature on the time-stamp token, include a
signed attribute that identifies the signer's certificate.

This identifier only allows SHA-1 [SHA1] to be used as the hash
algorithm to generate the identifier value.

The mechanism used in [RFC3161] employed ESSCertID from RFC 2634
[ESS]. RFC 5035 [ESSV2] updated ESSCertID with ESSCertIDv2 to allow
the use of any hash algorithm.

In general, SHA-1 fell out of favor for security utilizations and recently was officially denounced by NIST.

Suggestion

• Support ESSCertIDv2 / RFC 5816
• Implement SHA-2/SHA-3 either as a default of a configurable opt-in.

Related discussion

• #2

Verify conformance with specifications

• https://datatracker.ietf.org/doc/html/rfc3161 - Main RFC for timestamping
• https://datatracker.ietf.org/doc/html/rfc3628 - RFC for policy requirements that we need to adhere to (we set an OID for this RFC to denote that we're conformant)

An alternative policy for Apple's TSA: https://images.apple.com/certificateauthority/pdf/Apple_Timestamp_CPS_v2.0.pdf

We may need to create our own TSA policy with its own OID if we can't conform to 3628

Verification fails with libressl

Description

I am investigating why the verfication is failing when following the README steps. I tried both local deployment approaches and both are failing.

Verification: FAILED
4336174636:error:2FFFF065:time stamp routines:CRYPTO_internal:ess signing certificate error:/AppleInternal/Library/BuildRoots/a0876c02-1788-11ed-b9c4-96898e02b808/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2.8/crypto/ts/ts_rsp_verify.c:300:

where the timestamp inspection shows:

Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 0.4.0.2023.1.1
Hash Algorithm: sha256
Message data:
    0000 - e4 9a 89 7a ac 4c 98 19-21 27 0a 3f 79 e4 68 85   ...z.L..!'.?y.h.
    0010 - c9 95 2f c5 ba 1a b4 c0-cd ef 38 0b e7 73 74 81   ../.......8..st.
Serial number: 0x1F5E0336A9118E4020B3EC84C33B2C9E99E36505
Time stamp: Oct 13 17:53:10 2022 GMT
Accuracy: 0x01 seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x4CE5002F5E5F753A58F2B98124C3B6A732EE769B
TSA: DirName:/O=local/CN=Test TSA Timestamping
Extensions:

Go through TODOs in generated code

Description

Provide the timestamp value from a “verify timestamp” API

Right now, for https://github.com/sigstore/cosign/blob/9c7feb9362d623404c2712d0f8bb57a5977c9780/pkg/cosign/verify.go#L1017-L1023 , VerifyTimestampResponse calls timestamp.ParseResponse, but the caller needs to call that again because the Verify… function doesn’t return the existing value.

This is both inefficient (unnecessarily parsing twice) and unnecessarily a bit risky (the caller could possibly parse something else than was verified).

Ideally, VerifyTimestampResponse or some new related function should return the parsed timestamp object (only) on successful verification.

Add support for JSON format requests

Description

Currently the TSA only supports requests in the DER encoded TimeStampReq format defined in RFC-3161. Let's add support for making requests in JSON format.

This can be done with with content type request headers. If the Content-Type header is set to application/timestamp-query, the TSA will expect the request's body to be DER encoded in the TimesStampReq format. If the header is set to application/json, the service will expect a JSON format.

Address TODOs with package releases

Description

Conformance testing

Description

• Testing 3161 conformance
• Client conformance test

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch main

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

broken `--cert-chain` command line argument

Description

I started seeing CI failures, and it appears that the command line arg --cert-chain was renamed --certificate-chain

https://github.com/sigstore/scaffolding/actions/runs/3658333635/jobs/6182985071

I'm not sure how many clients are out there, but more of an FYI that this did (temporarily) break scaffolding CI runs

Implement a mock NTP client for testing.

Description

Getting unit tests for the ntp monitoring is non-complete as of now. By implementing an interface that captures the ntp client's functions, we can rely on dependency injection during unit test to get the monitoring part tested. This functionality does not yet exist, but proposed as of this PR #143

Update openssl verification steps to split up certificate chain

Description

--CAFile should contain only the root certificate, --untrusted should contain the leaf and intermediate certificates.

Security Policy violation Binary Artifacts

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

• hack/tools/bin/swagger

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Support gRPC API

This issue proposes adding an alternative API accessible over gRPC rather than HTTP.

TSA policy includes "dead" references.

Description

In the policy:
https://github.com/sigstore/timestamp-authority/blob/main/docs/tsa-policy.md?plain=1#L431
https://github.com/sigstore/timestamp-authority/blob/main/docs/tsa-policy.md?plain=1#L432
There are references to sub-points (f) and (d) but the list is unordered.

Suggestion is to make the list ordered and make sure the references are correct, as in the original RFC: https://datatracker.ietf.org/doc/html/rfc3628#section-7.1.1

Version

Latest main.