Idea: alias --cert-email as --cert-identity/--cert-san

[woodruffw]

Breaking this out for discussion from #107: --cert-email can be misleading when the OIDC identity in question isn't an email, but rather a GitHub workflow or other URL. We could provide CLI aliases that make this clearer.

cc @di for thoughts.

[jku]

Related: Github workflow certificate uses six other extensions in addition to SAN -- they must think verifying those have value, and the extensions there do seem useful. Other systems likely have different extensions they include.

So observations:

• A more generic --cert-extension <id> <value> could be useful (there are some potential problems with more complex datatypes but for the GitHub example this would work fine)
• --cert-identity or --cert-san probably still makes sense as a more readable short hand for this specific case

[woodruffw]

Related: Github workflow certificate uses six other extensions in addition to SAN -- they must think verifying those have value, and the extensions there do seem useful. Other systems likely have different extensions they include.

Yep. We've added the OIDs for those extensions in #117. We need to figure out which set of CLI options we should expose for them, which will involve some coordination with cosign...

[woodruffw]

Opened sigstore/cosign#1964 for cosign's side.

[woodruffw]

• A more generic --cert-extension <id> <value> could be useful (there are some potential problems with more complex datatypes but for the GitHub example this would work fine)

I think this is a good idea, although we probably want to think about the UX -- having <id> be a dotted-string is probably not ideal, so we'll probably want a standard set of human-friendly names that cosign and sigstore-python share.

[jku]

You must have noticed this already but since it's not written anywhere:

We previously discussed that --cert-email might already work to verify whatever fields are in SAN: this is untrue as cryptography API has different types for different kinds of SANs. In practice san_ext.value.get_values_for_type(RFC822Name) will only return the SANs that are emails, not URIs like the GitHub identifier.

[woodruffw]

Yeah, this is an unfortunate case where cryptography is more correct in a way that causes more work for us 🙂

We won't make any movement here until we get some consensus with cosign on sigstore/cosign#1964, so I'll follow up with some design thoughts there.

[woodruffw]

It looks like cosign has merged partial support for --cert-identity, so we should probably go ahead and do the same.

See: sigstore/cosign#2056