RFE: Allow verifying CN when verifying using certificates

[maxking]

Description

I have described how we are trying to use Cosign here, but in short, we provision identity certificates to all services and want to use those for signing and verification. So far, I've been able to sign using the cert and verify using kyverno (#1554: bug for verification usign cosign CLI).

Given that all certificates issued using the Root CA will be valid when verifying using the root CA, we want to limit the servicePrincipal/userPrincipals whose signatures are trusted. It is similar to what is described in the "Self-managed keys in identity-based code signing certificate with auditability" section in this blog post.

Currently, cosign verify command already has a bunch of --certitificate-* attributes, presumably intending to verify different attributes about the identity when using OIDC token. But the ask here to extend that to allow verifying CN for self managed certificates. Although, it would be better to support fields under X509v3 Subject Alternative Name as a more general verification.

[dlorenc]

Thanks for the details! This is definitely a case we should support. cc @znewman01

[haydentherapper]

Interesting question! Supporting verification of fields that aren’t set by Fulcio sounds like out of scope for Cosign. Fulcio only sets SANs, not common name. I think this should be a part of a verification engine. @znewman01 has outlined a new command “inspect” that would support such requests for verification of other fields, by returning structured info about the certificate, signature, etc to the caller.

If we do want to support verification of arbitrary X.509 fields, I think we are going to need to think through what that UX looks like. I’d rather not keep growing the list of certificate verification flags.

[maxking]

@haydentherapper Would you be okay with allowing SANs instead of CN in that case to be verified in the cosign verify command?

[haydentherapper]

Feature incoming! #1964

[znewman01]

+1 to the @haydentherapper's general sentiment: I really would prefer to avoid giving cosign verify a flag for every possible X.509 field/extension/etc.—this kind of "kitchen sink" UX is why e.g. openssl is so hard to use. Further, I think that we as tooling authors can't know what you're trying to check if you're using certs generated externally, and it's much better to make you tell us that explicitly.

This suggests to me the following conclusions:

• Cosign should have first-class support for verifying common patterns created by Sigstore infrastructure. This means we should decide what counts as a "common pattern."
• There should be an "escape hatch" for advanced use cases. cosign inspect (Add cosign inspect command. #2210) could be one option, or possibly passing a CUE template to cosign verify (as https://github.com/sigstore/policy-controller supports).

@maxking: I'm glad that for your use case the SAN verification will work. Let's leave this issue open to track the general issue of enabling verification for hybrid use cases (BYO certs).