Delegated Path Validation

A trust anchor is characterized by a public key, a Certificate Authority (CA) name, and a validity period; it may also have additional constraints.

[3] A self-signed certificate can be used to designate the public key, issuer name, and the validity period for a trust anchor.

In the response, the server must include either the certificate or a clear reference to it, especially in cases involving CA key compromises.

This extra information helps relying parties who do not trust the DPV server to be confident that the certificate validation was performed correctly.

For the client to prove to third parties that the certificate validation was handled correctly, the DPV response must be digitally signed, except when reporting an error.

[1] In certain network environments, particularly those with firewalls, a DPV server may encounter difficulties in obtaining all the necessary information to process a validation request.

Unlike end clients, DPV servers typically have more substantial computing and memory resources, enabling them to employ relaying, re-direction, or multicasting mechanisms.

[1] The protocols designed to support these operations may include optional fields and extensions to facilitate relaying, re-direction, or multicasting between DPV servers.

[1] The DPV protocol must incorporate mechanisms to prevent replay attacks, ensuring that malicious entities cannot reuse validation requests to gain unauthorized access.

[4] When a certificate is validated successfully according to the specified policy, the DPV server should include this information in the response if requested by the client.

[1] The revocation status information used by the DPV server pertains to the validation time specified in the client's request.