Improvements to verification for private repositories without log upload

[haydentherapper]

Description

I received some feedback that it's unexpected you need to explicitly opt out of tlog verification for a container hosted on a private repository when you don't have to explicitly opt out for upload during signing. I'm not sure there is a good way to improve this, but filing this issue so we can discuss more.

Some ideas:

• Alias the insecure-tlog-skip flag to something like private-repository which would result in the same behavior. I don't really love this though because it is technically "insecure" to skip uploading to a tlog for private artifacts, you aren't getting the auditability Sigstore recommends.
• Detect if the artifact is private during verification, and skip tlog verification if so. However, we then miss the case of an upload occurring on signing. We could require the user to set a flag to force tlog verification, but this isn't secure by default.
• Do nothing, and just document this.

[haydentherapper]

This came up again, in the context of insecure being misleading, particularly for systems where there's a closed loop between signers and verifiers. I'm leaning towards adding a flag like --private-deployment that disables requiring the SCT and SET promises. Another option is just to alias the insecure flag, which might be the better approach if the latter is going to require refactoring.

@znewman01 Any thoughts?

[znewman01]

I wonder if this is a nice excuse for different "verbs". What's secure/insecure differs dramatically between different deployments. We could also implement "profiles" with pre-configured verification options.

I'm going to tackle some of the internal refactoring (e.g. #2462) in the coming couple weeks. That should make this easier to implement without fear.

[melba-lopez]

Hi @znewman01 its not so much an excuse but an assumption made by Sigstore that may not be correct for all users. I want to preface the conversation with we <3 sigstore and I recommended it be used internally last year, which is why I'm here today 😄

We have a private deployment of cosign with plans to implement rekor (also private). We internally use a centrally CISO managed dedicated key management service and hardware security module (HSM) - using FIPS 140-2 Level 4 certified hardware. Our internal developers don't need to worry about key management and our product teams bake this into the build environment. As you can imagine we tightly control this for all of our products, especially when public sector is a concern. @lukehinds made an issue around FIPs compliant, which also highlights this concern. https://github.com/sigstore/sigstore-go/issues/30

Thus, one should not assume that a private implementation of Sigstore (whole suite or partial) is insecure because the artifact is signed in a private implementation, which is not open to the public domain. Transparency does not = security; just as being private does not = security. The claims of security should be attestations by the organization/provider/auditor.

When a customer goes to "validate" an artifact that is signed (i.e. an SBOM), they will be presented with what appears to be an error AND (regardless of knowledge of security) they will make misinformed decisions or assumptions because of the word "insecure" in the command insecure-ignore-tlog. We cannot expect our customers to "pin" their versions because they may not even understand what they are doing, or they are mandated to have the latest levels at all time.

So really what we are asking is to take into consideration a variety of ways a private implementation could be used. We should enable users to continue using Sigstore/cosign without the fear that the community/customers will label them "bad @ security" just because they chose a private implementation. Obviously we would need to take into account someone trying to fake using a "private" instance when in fact they are not. I'm hoping this is already taken into account but definitely understand wanting to flag the lack of using transparency logs.

Welcome further discussions as I have had with @haydentherapper :)

[dylrich]

I am curious if we could start the conversation about this issue again. We have our own transparency log with keys backed by an HSM that is tightly controlled. We would prefer to rely only on our own infrastructure for signing and transparency, and we don't want customers to get the wrong idea when they go to verify by having to type the word "insecure". Could we consider adding a "--private-transparency-log" flag or something less scary in nature that both skips the Sigstore specific checks as well as doesn't log a warning? I understand that using Sigstore's public transparency log is a good default for most users who do not have specific infrastructure provisioned, but it'd make adopting Cosign easier for larger organizations that tend to want to run their own private setups for one reason or another.

[haydentherapper]

I am supportive of having that flag name be an alias for the existing flag. Long term, I’d love to see us split out cosign into the “expected” workflow with a code signing CA and transparency log, and a bring your own verification workflow which relaxes many constraints. Realistically that’ll take a bit of time to design and implement, so an aliased flag in the meantime seems reasonable.

@dylrich do you want to add that?

[dylrich]

I am open to being involved in both of those! If you have a particular name you'd prefer for an alias I would be happy to submit a PR for that. How do you feel about the warning message being silenced if you use the alias?

[haydentherapper]

private-infrastructure or private-deployment would be my preference - private-transparency-log isn't accurate since this would be used when there is no transparency log. I'm good with the warning being silenced too.

[dylrich]

Sounds great! I will give it a whirl tonight.