Custom values for O, OU and C

[mikn]

We want to send more information on the certificate than just CN to indicate heritage of the key, mainly what helm-chart they belong to, but also to read up "roles" for authorization.

(edit: I hijacked this issue because I realised my previous task was already addressing the original subject)

[johngmyers]

For context, I've been approaching this from the perspective that only the SANs matter.

How would the approval flow know how to validate these fields?

You'd be encoding roles in the O/OU?

[mikn]

Currently I am, yes. I think the approval flow could validate O/OU based on labels on the containers, perhaps? So you can say that allowed values for O/OU are values that needs to exist as labels.
The use case here are systems that use parts of the principal to establish role/groupings of users. So you can have several pods in a deployment that have unique CNs, but still have them grouped into the same permissions based on other components of the principal.

[johngmyers]

I'll mention that this is an inadvisable misuse of the subject field. Such things should be in separate extensions, presuming you don't want to go full attribute certificate. The web PKI has suffered from its misuse of the CN field for domain names and browsers are making moves towards finally ignoring any domain in the CN.

Allowing additional flags for specifying these seems like it would be sufficiently localized to be accepted.

[mikn]

Are there any X.509 extensions that could be used to fill a similar function? I could suggest it to upstream rather than the one outlined here.
I do however think that as you conclude, that this is an 'ok' feature to have with the imposed limits, no matter whether we can convince people to stop abusing the subject. :)

[johngmyers]

That is a bit outside of my knowledge of X.509.