Client libraries should verify after signing

[znewman01]

In the Sigstore clients special interest group meeting today, we discussed an issue with the release signatures on CPython.

We have two recommendations for client libraries:

1. After signing, the clients MUST verify the signature (see Sigstore client spec). 2.
2. Client library interfaces SHOULD allow callers to specify an identity (and other verification parameters) to use for this verification.

I'm going to be a bit lazy (sorry) and rather than inspecting every client library by hand, just ask whether you're doing the these and, if not, whether you all agree with these recommendations.

[woodruffw]

I don't believe we currently do either of these 🙂.

I'm open to changing my mind here, but I'm currently a little bit murky on the value of mandatory verification after signing. The main things I'm skeptical about:

1: Asking users to pass verification state in during signing

Under recommendation (2), clients like sigstore-python would (IIUC) essentially mirror their current sigstore verify ... CLI within the sigstore sign CLI. I think this is may cause problems worse than the ones it solves:

1. There isn't consensus among Sigstore clients around the minimum set of claims needed for a "coherent" verification yet (besides the most basic "identity" verification of SAN + issuer). Exposing additional verification surfaces here will double the amount of state that users (at least, users doing things securely) will need to understand in order to perform basic signing operations.

2. This can fail open in (IMO) nasty ways: the goal here is to prevent Incorrect information in https://www.python.org/download/sigstore/ #600, but the issue is more generic than just that instantiation. For example: a user might think that they're checking the "expected" identity of a newly minted signature by checking that the SAN and issuer match their expectations, but the actual verifying party is expecting even further claim restrictions.

2: Checking error states rather than preventing them

Related to the above: I think the underlying problem here (users signing with the wrong or "unexpected" identity) is a very serious one, and needs to be addressed.

At the same time: I think mandating verification (particularly of claim states) after signature generation results in a situation where Sigstore clients are performing "guess and check" error handling rather than eliminating these kinds of user-initiated error states from the very beginning.

They're arguably harder to do, but I think three workable "eliminate the error state" solutions are:

1. Allow clients to restrict the IdPs presented during signing. Rather than hoping that the user clicks on the right IdP (and identity within the IdP) during the signing flow, it might be nice to have a way for Sigstore clients to signal to Dex that they only want a subset of the IdPs presented for the user to select from. For example, sigstore sign ... could become sigstore sign --idp=google ..., effectively preventing a user from ever producing a signature with another issuer by accident. I can't find it right now, but I believe this idea has been brought up before.

2. Give clients more visibility into the ultimate signing identity. At the moment, each IdP wrapped by Dex "takes over" and has a different UI for presenting the identity/identities underneath it. It would be nice (if possible, which it may not be) to somehow unify these different UIs and ensure that a signing user is always routed through a consistent and uniform set of signing identities. I believe this would go a long way towards reducing user error here.

3. Solve this at the signature ingest level. Just like Sigstore punts on the problem of identity trust management, I think Sigstore would probably be best off to punt on the problem of sorting valid signatures from valid-but-contextually-wrong signatures. In other words: if a system like the CPython release system needs to ensure that it only distributes certain identities, then it should perform those checks on its own (ideally by calling sigstore sign ... or similar directly!)

3: Mandating a less secure verification mode

This is a more abstract concern: if my interpretation is correct, a client following these recommendations is effectively required to implement a "no-op" verification mode, one where a signature is said to be valid without cross-checking any of its embedded claims.

This is not risky in the context of a signing flow, but I think it's worth highlighting that this effectively requires clients to implement a codepath where users may think that they're doing something resembling a normal Sigstore verification flow but are really just checking that any signature is valid for some input. I think this is especially concerning in the context of clients that provide an API; it's hard to provide a misuse-resistant version of an API that explicitly allows all relevant pieces of verifiable claim state to be omitted!

---

If I had to rank these concerns, I'd say that (2) is the most important, followed by (1) and then (3).