Alert only for certificates issued from a set of trusted roots

[haydentherapper]

Description

Rekor accepts certificates from any issuer, including self-signed certificates. A malicious entity or spammer could issue certificates using someone's identity and OIDC issuer to trigger an alert for a monitor. This can be mitigated by verifying the certificate chains up to a trusted root. For the public instance, the monitor can pull in the trusted PKI from Sigstore's TUF repo.

This should be configurable, since this may be used for self-hosted instances.

[haydentherapper]

One comment from the linked thread on rekor is that it is possible to have a freeze attack against local metadata up to the expiration of the timestamp. This would delay fetching the latest trust root and could result in an entry being ignored. We could add a configuration to always fetch the latest TUF metadata regardless of timestamp if this is a concern based on the users threat model.

[Horiodino]

Hey @haydentherapper, this issue looks quite interesting! Is it okay if I take it on? Let me know if there are any references or guidelines on where to make changes, and if the issue is still open.

[haydentherapper]

Of course, thanks!

For some background info: Sigstore ships its root of trusts to verify certificates and log entries via TUF.

I'd suggest first tackling #51, to integrate a TUF client and fetch the log public keys in

rekor-monitor/pkg/ct/consistency.go

Line 45 in f4bd8b5

pubKey, err := cryptoutils.UnmarshalPEMToPublicKey([]byte(ctfe2022PubKey))

and

rekor-monitor/pkg/rekor/verifier.go

Line 35 in f4bd8b5

func GetLogVerifier(ctx context.Context, rekorClient *client.Rekor) (signature.Verifier, error) {

. You'll see an example of a TUF client implemented in https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf. That will make this issue smaller in scope.

This issue is specifically about narrowing down which certificates are verified from the log. The log contains both certificates issued from Sigstore's CA and from private CAs. When monitoring entries for specified IDs, users are going to only want to search for certificates that come from CAs they trust. Otherwise, someone could issue a certificate for "hayden@website" from their own private PKI, upload it to the log, and my monitor would alert.

For tackling this issue, I'd suggest creating a configuration for the set of trusted roots that certificates should chain up to. By default, it should pull from Sigstore's TUF metadata. Both the TUF root and the set of CA roots should be configurable, to handle private PKI use cases. Every certificate found in the log should be verified using the set of trusted roots. If verified successfully, only then we should check for the specified identity.

Regarding this comment, we should configure the TUF client to always update to the latest metadata (which is a setting when configuring the client).

Let me know if you have any questions!