Fix cross-vault OCSP snapshot poisoning

ocsp-responder/README.md

@@ -8,7 +8,7 @@ It has **no KCA database access**, no Redis access, and no KCA master key. It
 only needs:
 
 - `s3:GetObject` on the configured bucket/prefix;
-- the CA certificate for each issuer;
+- the CA certificate and its KCA CA UUID for each issuer;
 - a delegated OCSP signer certificate and private key for each CA. The
   responder currently accepts RSA-SHA256 and ECDSA P-256 signers in PKCS#8,
   PKCS#1 RSA, or SEC1 EC PEM form.
@@ -18,16 +18,30 @@ only needs:
 KCA publishes objects as:
 
 ```
-<prefix>/<CA certificate SHA-256>.json
+<prefix>/<KCA CA UUID>.json
 ```
 
+Set each issuer's required `ca_id` to the UUID of its CA certificate row in KCA.
+This isolates snapshots when the same public CA certificate exists in multiple
+vaults. The responder validates both this ID and the CA certificate fingerprint
+against every downloaded snapshot.
+
 KCA publishes these objects when `KCA_OCSP_S3_BUCKET` is configured. The JSON
 contains all certificates issued by that CA, both valid and revoked. The
 responder never infers status from a partial revoked-only list.
 
+## Upgrading from fingerprint-named snapshots
+
+Deploy the updated responder with `ca_id` before or together with the updated
+KCA publisher. The responder deliberately does not fall back to legacy
+`<prefix>/<CA certificate SHA-256>.json` objects. Until KCA publishes the new
+objects, OCSP requests return `tryLater`. After verifying the new snapshots,
+the obsolete fingerprint-named objects can be removed.
+
 ## Run locally
 
-1. Create a config based on `responder.example.yaml`.
+1. Create a config based on `responder.example.yaml`, setting each issuer's
+   `ca_id` to its CA certificate UUID in KCA.
 2. Put your CA certificates and delegated signer files where the config points.
 3. Export standard AWS credentials / endpoint variables as needed.
 4. Make the signer key readable by the container user (`65532:65532` in the