TL;DR: On GitHub Actions, the "identity" we embed into the CSR is the sub claim from a GitHub Actions OIDC token. That sub claim contains the job's environment, which can contain non-ASCII characters (like UTF-8 emojis).
Consequently, Fulcio throws a 400 with a malformed CSR when we submit.
This has two aspects to it:
- I'm a little surprised pyca/cryptography actually allows us to build this CSR -- if Fulcio is right and the email is encoded as an IA5String, then we might be generating invalid DER here.
- Separately, we need to see if we can encode this as something other than an IA5String, or maybe change the CSR subject to something other than an "email" (since that's incorrect anyways).
The latter might actually be really simple: per sigstore/fulcio#863 Fulcio doesn't actually use this field at all, so we can probably just put a stub value into it and carry on as normal.
See pypa/gh-action-pypi-publish#376.
TL;DR: On GitHub Actions, the "identity" we embed into the CSR is the
subclaim from a GitHub Actions OIDC token. Thatsubclaim contains the job's environment, which can contain non-ASCII characters (like UTF-8 emojis).Consequently, Fulcio throws a 400 with a malformed CSR when we submit.
This has two aspects to it:
The latter might actually be really simple: per sigstore/fulcio#863 Fulcio doesn't actually use this field at all, so we can probably just put a stub value into it and carry on as normal.
See pypa/gh-action-pypi-publish#376.