RA: compute CRL shard upon revocation #7133
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add three new config values to the RA: crlDPBase, crlNumShards, and crlShardWidth. When a revocation request comes in, use these values to compute the CRL Shard that the revoked cert falls into, and include that shard number in the RevokeCertificate request to the SA. This will cause the SA to create a row in the revokedCertificates table, thanks to #7095.
The first new config value is used to extract the appropriate shard number from a CRL Distribution Point URL already embedded in the to-be-revoked certificate. Therefore, this value must exactly match the crlDPBase config item in the CA, which controls the CRL URLs it generates.
However, that method only works once CRLDP URLs are baked into certs, which isn't the case yet. So the second and third new config values are used to directly compute the appropriate shard based on the certificate's notAfter date, in the same way that crl-updater computes that mapping today. Therefore these values must exactly match the crl-updater's numShards and shardWidth config values.
All of the code described above only becomes active once all three new config fields are specified in the RA. This allows this change to be deployed safely, and turned on later by setting those config values.
Also update the RA's audit log for administratively-revoked certificates to include the correct revocation method name.
Part of #7094