Summary

  • RFC 5276 binds long-term Evidence Records to exact certificate, path and revocation responses returned by SCVP; it preserves validation material rather than issuing a timeless universal verdict.
  • A defensible historical decision must still prove the responder, requested time and policy, trust-anchor choice, archived signature, later revocation knowledge and application authorization.

Imagine an archive that can reproduce, byte for byte, the certification path used to validate a signature twenty years ago. Every certificate is present. The revocation material is preserved. Archive timestamps have been renewed before old algorithms became weak. The SCVP response is signed, and its Evidence Records verify.

Another relying party can still reject the result.

That is not a failure of long-term evidence. It is the point at which evidence ends and authority begins. The second relying party may not trust the same responder key. It may reject the trust anchor carried with the response. Its application may require a different certificate policy or key purpose. It may possess later revocation information whose invalidity date reaches back before the historical validation time. Or the archived file may fail to verify under the returned end-entity certificate even though the certificate path itself was preserved perfectly.

RFC 5276 is valuable because it gives those disagreements a precise technical surface. It combines the Server-Based Certificate Validation Protocol, or SCVP, with Evidence Record Syntax, or ERS. SCVP answers questions about certificate-path construction and validation. ERS maintains evidence that exact data existed with integrity at a time, renewing that evidence as algorithms and credentials age. RFC 5276 associates the two. It does not turn their association into jurisdiction over every later decision.

The receipt covers returned bytes

SCVP has a WantBack mechanism: the client asks the server to return specified information along with its validation answer. RFC 5276 adds identifiers for Evidence Records covering an end-entity certificate, a complete certification path, a partial path, revocation information, or all returned WantBack material.

The association is deliberately exact. If a client requests evidence for a complete path, it must also request the complete path. The response must carry both. The Evidence Record covers the DER-encoded certificate bundle returned in the corresponding response field. For a single certificate, it covers the certificate value. For revocation information, the server returns evidence that can be associated with each CRL or OCSP response; one record may cover several items, but the verifier must locate the relevant hash in the first archive timestamp.

The aggregate form makes the bookkeeping explicit. Each entry names the type of returned information it covers, and RFC 5276 requires one-to-one correspondence with the other WantBack replies. The standard is not asking the verifier to admire a sealed envelope. It is asking the verifier to show which seal covers which bytes.

That scope is powerful and narrow. A valid Evidence Record can show that a particular path bundle or revocation response existed with integrity across the preservation period. It cannot, by itself, show that those bytes describe the correct signer for the archived file, that every later fact was already known, or that the relying application should authorize a consequential act.

Missing evidence is not a negative verdict

RFC 5276 also defines an honest failure shape. If the server cannot return an Evidence Record for a requested item, it still returns the evidence-record reply type with an empty value. In the aggregate structure, the Evidence Record field is absent for the relevant target. If the client asks for an Evidence Record without asking for the covered information, the server marks the WantBack as unsatisfied.

Those states matter because operational dashboards are tempted to compress them. “No evidence record” can become “certificate invalid.” “Request processed” can become “evidence complete.” Neither follows.

An empty evidence field says the requested preservation proof was unavailable. The underlying certificate-status answer may be positive, negative or indeterminate under its own fields and policy. Conversely, an Evidence Record that verifies does not make a negative status positive. Evidence availability and certificate validity are independent dimensions.

A useful control plane therefore needs at least four states: the validation request was understood; the requested certificate or path material was returned; preservation evidence for each item was returned and verified; and the validation verdict under the stated policy was determined. Collapsing them into one green icon destroys the diagnostic value RFC 5276 created.

Complete and partial paths move the assembly boundary

The standard supports two storage models. A complete path can include the end-entity certificate through the trust anchor and be preserved as one returned bundle. A partial path begins with the issuer of the end-entity certificate and continues upward. The signer certificate may instead travel inside the archived file and be protected by the archive's own Evidence Record.

Partial preservation reduces duplication. Many archived files from the same period can reuse the same issuer-to-anchor material without storing a complete path for every signer. That is an attractive systems optimization. It is not merely a smaller encoding.

It moves the assembly boundary to verification time. The verifier must prove that the end-entity certificate obtained with the archived file was preserved with that file, that the file's signature verifies under that certificate, that the certificate connects to the separately preserved partial path, and that the relevant revocation material covers the needed interval. A clean partial-path Evidence Record can coexist with a broken archived signature or a mismatched signer certificate.

The storage saving therefore creates a future dependency map. Whoever designs the archive must record where the end-entity certificate lives, how it is bound to the file, which SCVP material completes the path, and which policy inputs are needed to reproduce the historical decision. Without that map, every component can survive while the proof cannot be reconstructed.

The trust anchor enters as policy

Certificate-path validation is often described as if the path itself contains its own authority. RFC 5280 says otherwise. The trust anchor is an input to the validation algorithm. Different applications may rely on different anchors, and a path that is valid under the base algorithm may still be inappropriate for a particular application. Applications may impose further limits.

RFC 5055 carries that policy surface into SCVP. The request can select a validation policy, time, trust anchors, key usages, extended-key usages, revocation behavior and other parameters. A short request may rely on server defaults. But if a client later needs to prove which full policy was used, it must obtain enough of that policy and its parameters in the response or preserve them elsewhere.

RFC 5276 adds another trust decision. The SCVP response containing ERS structures must be verified with a public key trusted by the relying party. Trust anchors carried inside the signed response may support verification of interior ERS layers, but the relying party may use them or ignore them in favor of anchors obtained out of band. Anchors in an unsigned response should be ignored.

This produces a precise hierarchy. The Evidence Record can protect the bytes of a returned certificate path. The SCVP response signature can authenticate the server's statement. Neither chooses the relying party's responder key, trust-anchor policy or application purpose. Those remain local decisions. A preserved answer is portable evidence, not portable command.

Historical truth can be revised by later evidence

SCVP permits a client to request validation at a time in the past. The server formats its processing as of that validationTime, provided it holds suitable historical information. That feature is essential for archives: a certificate that is expired today may have been valid when the signature was created.

But RFC 5055 states a crucial limit. Historical validation reports the known status at the requested time; it may not be the most complete information later available. A certificate might be revoked after the query, while the revocation notice gives an invalidity date earlier than the historical time. An earlier affirmative answer can therefore be authentic, correctly preserved and later overtaken.

That is not a cryptographic contradiction. It is an information-timeline problem. The first response proves what the responder asserted with the information and policy available then. The later revocation evidence changes the decision record. Long-term verification needs both acquisition time and subject time: when did the certificate purportedly have a status, and when did the verifier learn the information used to assess it?

OCSP's archive-cutoff mechanism expresses a related limit by describing how far historical status material is retained. It contributes evidence about what the responder can answer; it does not guarantee that no later fact will alter the interpretation.

An archive that preserves only the first affirmative response can be internally pristine and externally obsolete. A defensible system retains policy versions, later revocation discoveries and decision supersession rather than treating immutability as immunity from new evidence.

Evidence Records themselves require maintenance

ERS is sometimes imagined as a permanent seal applied once. RFC 4998 describes a maintenance process. An archive timestamp proves that an item or group existed at a time. Before its timestamp credential or public-key algorithm becomes unacceptable, a timestamp renewal covers the previous timestamp. If the hash algorithm protecting the tree becomes weak, a hash-tree renewal covers the older timestamps and archived data under a new construction.

The newest layer becomes the current watch point, but earlier layers remain part of the chain. Long-term confidence therefore depends on renewal timing, algorithm policy, preserved validation material and the ability to reproduce the covered hash path.

ERS also contains an instructive warning about supporting metadata. Its optional cryptoInfos can hold trust anchors, certificates, revocation information or historical algorithm-suitability data. RFC 4998 says those fields are not protected by an archive timestamp and must be verified through other means. A useful container is not automatically a trusted container.

That distinction should shape operations. Teams should not report “the Evidence Record contains the trust anchor” as if containment were authentication. They should report which timestamp covers which data, which additional fields sit outside that coverage, how those fields were verified, and when the chain next requires renewal.

A historical decision needs a proof graph

The minimum useful audit record is not one status field. It is a graph of linked receipts:

  1. the archived file and its digest;
  2. the actual signature and the certificate used to verify it;
  3. the requested historical time;
  4. the selected validation policy and every material override;
  5. the acceptable trust-anchor set;
  6. the SCVP responder identity and response-authentication result;
  7. every returned certificate, path and revocation item;
  8. the exact Evidence Record associated with each returned item;
  9. the verification result and renewal history for each Evidence Record;
  10. later revocation or policy information that supersedes an earlier decision;
  11. the application-specific authorization decision; and
  12. the downstream action, if any.

This is not documentary excess. Each edge answers a different failure. A path may verify under the wrong anchor. A response may be authentic but replayed if its request nonce is not checked. An Evidence Record may cover a path that does not contain the certificate actually used on the file. A historically correct status may be superseded. A cryptographically valid signature may have no authority for the business action attributed to it.

The graph makes those failures local. It lets an operator repair one missing edge without pretending the whole archive is worthless or the whole proof is complete.