Summary

  • RFC 3029 defined a Data Validation and Certification Server whose signed result could truthfully report that validation failed; service execution, response authenticity and subject validity were separate facts.
  • The Data Validation Certificate bound the request or imprint, time, serial number, policy, collective status and detailed results, so a relying party still had to verify both the response and the meaning of its verdict.

The word certificate encourages a dangerous shortcut. It sounds like approval made portable. In public-key systems, however, a certificate can carry many kinds of assertions, including a carefully authenticated negative one. RFC 3029 used “Data Validation Certificate”, or DVC, for the signed product of a validation service. The DVC did not promise that the submitted object was sound. It promised that the server had produced a policy-bounded statement about it.

That distinction was unusually candid. The specification says a DVCSCertInfo structure is returned after successful execution of a data-validation service, then immediately warns that successful execution does not imply successful validation. The structure may contain a valid or an invalid result. A request can be well formed, accepted and processed; the response can be correctly signed by the server; the underlying signature or certificate can still fail.

Four services, four different propositions

RFC 3029 described a Data Validation and Certification Server as a trusted third party and offered four services. Their names were similar, but the facts they could support were not interchangeable.

Certification of Possession of Data, cpd, required the actual data to be presented. Its result could support the proposition that the requester possessed those bytes at the indicated time and delivered them to the server. Certification of Claim of Possession of Data, ccpd, accepted a message digest instead. The server could certify that the requester presented that imprint; it did not thereby observe the original bytes. Calling both outcomes “proof of possession” without the service type would erase the most important evidentiary difference.

Validation of a Digitally Signed Document, vsd, went beyond checking a mathematical signature. The server could inspect certificate paths, status information and trust under the applicable policy. Validation of Public Key Certificates, vpkc, evaluated one or more certificates at a specified time, including path and revocation information. A DVCS might consult CRLs, OCSP, directories or another validation service, but RFC 3029 expressly did not present DVCS as a scalable replacement for CRLs or OCSP in large open environments.

The four services therefore answered different questions: were bytes presented; was an imprint presented; did a signed document satisfy the chosen validation rules; did a certificate satisfy the path and status rules at a time? A single green “verified” badge would have collapsed all four.

The signed response was a structured receipt

The DVC was a CMS SignedData object. Inside it, RFC 3029 kept several pieces of the decision separate. The request information identified the service and relevant request context. A message imprint bound the result to the submitted material. A strictly increasing serial number distinguished the certificate. A response time anchored the act and could itself come from an external timestamp token or another DVC, which the server then had to validate. A policy field identified the rules used. A collective status summarized the result, while certificate or signature elements could preserve individual outcomes and reasons.

This anatomy matters because a signature over the envelope proves neither that the client asked the intended question nor that the answer means what the application assumes. RFC 3029 told the requester to check the acceptable time, DVCS identity, request information, message imprint, signature, status, service and policy. The requester also had to assess the DVCS signing certificate. Only after those checks could the response be used as an authenticated validation statement.

The policy field was not ornamental. Two validation services could receive the same object and reach different defensible results because they trusted different roots, accepted different certificate policies or required different numbers of signatures. The portable evidence was therefore not “object X is valid everywhere”. It was “server Y, at time T, under policy P, returned result R for request and imprint Q”.

A collective result could conceal a mixed set

Documents and certificate sets made the boundary sharper. For certificate validation, a collective failure could mean that one or more elements failed; the per-item TargetEtcChain data identified which. For a signed document, one bad signature did not automatically invalidate the document. A policy might require only a sufficient set of signatures and return grantedWithMods. Conversely, individually correct signatures might still be insufficient if the policy required more signers or a different combination. granted was reserved for the case in which all signatures verified successfully.

The summary status was therefore an index into a decision, not a substitute for its detail. A dashboard that copied only the collective field could hide the failed signer that mattered to a particular relying party. A dashboard that displayed every mathematically correct signature could still miss a policy-level failure. RFC 3029 encoded both layers because neither could safely stand in for the other.

WAITING added a time dimension. It meant no final response was yet available, with later handling left to service policy. It was not a soft success. Treating a waiting token as permission would convert incomplete evidence into authority.

A signed negative result was not an error response

RFC 3029 also separated two kinds of failure that interfaces often merge. If the service executed, the DVC could carry an authenticated negative validation result. If the request could not be executed—for example because it could not be parsed or requester authentication failed—the server could return an error notification instead. The first answered the validation question with “no”. The second said that the server could not reach the question’s merits.

There was an even harder boundary. If the DVCS could not produce a valid signature, perhaps because its signing key was known to be compromised, it could wrap the error in a CMS structure with no signer information. Clients were required to treat that unsigned response as critical and fatal and not implicitly trust its contents. An unsigned “invalid” message was not authenticated negative evidence. It was a failure of the response authority itself.

That rule prevents a common inversion. An application must not trust an unsigned error because its words sound cautious, while distrusting a signed negative DVC because it lacks the desired positive result. The signed negative result can be valuable evidence. The unsigned error cannot silently inherit the DVCS’s authority.

The experiment moved trust; it did not erase judgment

RFC 3029 was published as Experimental, not as an Internet Standard. It records a design that the authors said was stable enough to invite implementation but still premature for the standards process. Later work separated delegated path-validation requirements in RFC 3379 and standardized SCVP in RFC 5055. Those later documents provide context; they do not prove adoption or success of the 2001 protocol.

The historical importance of RFC 3029 lies elsewhere. It attempted to centralize technical validation while preserving the shape of the evidence. Trust in the server moved into the signed DVC, but the result remained tied to a service, a policy, an imprint, a time and a status. The relying application still had to decide whether that statement was acceptable for its purpose.

Sources

Lu Heng did not author or endorse RFC 3029 or the related PKIX standards. His essays are used here as disclosed analytical lenses.