Allow admin command to block key from a CSR file

[mcpherrinm]

One format we receive key compromise reports is as a CSR file. For example, from https://pwnedkeys.com/revokinator

This allows the admin command to block a key from a CSR directly, instead of needing to validate it manually and get the SPKI or key from it.

I've added a flag (default true) to check the signature on the CSR, in case we ever decide we want to block a key from a CSR with a bad signature for whatever reason.

[aarongable]

nit: the test only covers one path through the new function: the signature is bad, but we're not checking it. It would be nice to have tests for a) the signature is good and we are checking it, and b) the signature is bad but we are checking it.

[andygabby]

I worry a bit that it could be a foot gun. A CSR isn't always proof of control of a private key and this could trigger bad-key-revoker to revoke certificates without proof of key compromise. Perhaps we should check the subject for a particular set of phrases and require the CSR to have a subject that matches.

Even better would be if the requestor used acme to revoke the certificate with proof of key compromise which already supports blocking of the key.

EDIT: In a side discussion I was reminded that an operator has to use admin block-key which is probably explicit enough to avoid someone not knowing what they are doing. This operational path is at the discretion of the operating CA to decide if it is appropriate.

[mcpherrinm]

b) the signature is bad but we are checking it

This case is tested already, I could add a "Signature is good" test too, and I can see value in that.

[jsha]

an operator has to use admin block-key which is probably explicit enough to avoid someone not knowing what they are doing.

It's important to have this sort of manual override, but I think it's also important to support human operators with as much automation as possible. I think this mode should have a second flag, -expected-cn. Since there's mainly one person who reports compromised keys using CSRs, and they always use the same CN, I think it's okay to default it to that value.

Basically I agree with @andygabby's original take: this should have an additional guardrail on by default.

Also, what do you think of audit-logging the CSR we relied on? And perhaps its parsed Subject for convenience?

[aarongable]

(I believe we're waiting for this PR to grow a "check the subject is an expected value" flag, which @jsha indicated he would contribute.)

[mcpherrinm]

Also audit logging of the CSR too. I have other things to do today but could get to this tomorrow.