Looks like the following are requested by the customer in addition to what's addressed in https://bugzilla.redhat.com/show_bug.cgi?id=1471935#c17

1.
Customer:
"
...
Something else that would be nice to have is a configuration option that would allow certificate issuance to fail if the encoding type in the CSR does not match the encoding type specified in the RHCS configuration. This would need to be something that can be turned on/off though.
"
my interpretation:
A constraint that enforces the encoding in the CSR.

2.
Customer:
"
You have RHCS configured to override the CSR encoding, then there is another RHCS config option that specifies what to do if the CSR encoding does not match the RHCS configured override encoding. So if a UTF8 CSR is submitted but RHCS is configured to override this with Printable String you could have RHCS just stop and not attempt to move forward with certificate issuance if this new config option was set a specific way (maybe true or false). Then if the new config option was set the opposite way RHCS would change the encoding to Printable String and proceed with certificate issuance. That's the idea I had, not sure if it makes sense.
"
My interpretation:
An "override" flag to the constraint to either throw error or just override with  CA's own encoding.

3.
Also from https://bugzilla.redhat.com/show_bug.cgi?id=1471935#c20:
"
The problem is the customer cannot control how the subordinate CAs are encoding the subject DN in certificate request in recent deployments (blocking) when a third party CA above those subordinates CAs has a different subject DN encoding.
The configuration workaround only works for the existing RHCS internal certs.
"
(Marc, please provide customer's exact wording...)
My interpretation:
new pkispawn configuration param to specify encoding format of the CSRs we genedrate during installation.