Add administrative X.509 certificate revocation

[tedmalone]

Name of feature:

Administrative X.509 certificate revocation.

Pain or issue this feature alleviates:

Administrative integrations may authorize a revocation before calling into the certificate authority. The existing revocation path expects an OTT or requester certificate so that it can recover authorization metadata, leaving these callers without a direct X.509 revocation entry point.

Why is this important to the project (if not answered above):

This adds an explicit entry point for already-authorized revocations while reusing the existing CAS, persistence, linked CA, and CRL behavior. It avoids duplicating revocation logic or constructing artificial OTT or mTLS state.

Is there documentation on how to use this feature? If so, where?

The exported type and method include Go documentation describing the authorization requirement. This change does not add a command, configuration option, or HTTP endpoint.

In what environments or workflows is this feature supported?

X.509 revocation workflows where the caller has already authorized the action and can provide the certificate being revoked. The operation supports the configured CAS, local or linked CA persistence, passive revocation, and generate-on-revoke CRLs.

In what environments or workflows is this feature explicitly NOT supported (if any)?

This method does not perform authentication or authorization. It is not a public HTTP endpoint, does not revoke SSH certificates, and does not support serial-only administrative revocation.

Testing:

• V=1 make test with Go 1.25.14 and Go 1.26.7 on Linux
• V=1 make build with both Go versions
• go vet ./...
• Targeted race tests for the existing and administrative revocation paths
• Smallstep shared golangci-lint configuration
• govulncheck ./...
• Generated-file and module-tidiness checks

[CLAassistant]

All committers have signed the CLA.