Do we need a way to adjust CSR attributes to cancel fields

[mcr]

Do we need a way to adjust CSR attributes to cancel fields

[mcr]

The "usual" way to deal with this problem is for the Registrar, using it's privileged relationship with the CA to rewrite/change/override the CSR attributes. The CSR itself is signed by the pledge, so the CSR itself is immutable.
This issue isn't exactly a brski-cloud issues, except as much that a) the pledge may be redirected to an RFC7030 EST Registrar that does not know what's going on, b) the cloud registrar may wish to be backed by an ACME CA in the cloud, to which the Registrar does not have as many privileges.

Maybe this is more of an ACME Integrations issue!

Taking this to the list.

[upros]

"using it's privileged relationship with the CA to rewrite/change/override the CSR attributes. The CSR itself is signed by the pledge, so the CSR itself is immutable."

So... the Registrar has to send some signal outside but along with the CSR to the CA, telling the CA "ignore attribute X value Y in the CSR and use value Z instead" ??

[mcr]

So... the Registrar has to send some signal outside but along with the CSR to the CA, telling the CA "ignore attribute X value Y in the CSR and use value Z instead" ??

I don't know how that works. I'm not sure if there is a public standard for it. I know that quite a number of commercial CAs have bespoke APIs that support this, but I don't know how they work.

[mcr]

We can, in the CSR attributes, tell the pledge to include a specific randomized, serialNumber in the CSR, one that has meaning in the Enteprise, but is not PII.