Delegated Path Validation

Last updated

Delegated Path Validation (DPV) is a cryptographic method used to offload the task of validating the certification path of digital certificates from the client to a trusted server. [1] This process is integral to various security protocols that rely on Public Key Infrastructure (PKI). DPV aim to enhance the efficiency of certification path validation by leveraging a server dedicated to this task, which provides validation results to the client. This approach is particularly useful in resource-constrained environments where clients may not have the computational power to perform extensive certificate validation themselves. [1]

Contents

Certificate path validation

Diagram illustrating the chain of trust of a digital certificate, showing the hierarchy from the root CA to the end-entity certificate. Digital certificates chain of trust.png
Diagram illustrating the chain of trust of a digital certificate, showing the hierarchy from the root CA to the end-entity certificate.

Certificate path validation is a crucial process in PKI that ensures the authenticity and trustworthiness of a digital certificate. This process is standardized in RFC   5280 and involves verifying a chain of certificates, starting from the certificate being validated (the end-entity certificate) up to a trusted root certificate authority (CA). [2] The validation process includes several key steps: [2]

If all these checks are successfully passed, the certificate path is considered valid, and the end-entity certificate can be trusted. [2]

Validation policy

DPV allows a server to handle the entire process of path validation based on a set of predefined rules known as a validation policy. [1] This policy may involve multiple trust anchors. 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. Additional constraints for trust anchors can be defined, such as certification policy constraints or naming constraints. These constraints can also be part of self-signed certificates. [1] For successful path validation, a valid certification path must be established between the end-entity certificate and a trust anchor, ensuring that none of the certificates in the path are expired or revoked, and all constraints on the path must be met. [1] A validation policy consists of three main components: [1]

  1. Certification path requirements: these define the sequence of trust anchors needed to start the certification path processing and the initial conditions for validation;
  2. Revocation requirements: these specify the checks needed on the end-entity and CA certificates to ensure they have not been revoked;
  3. End-entity certificate specific requirements: these may require the end-entity certificate to include specific extensions with certain types or values.

Protocol requirements

RFC   3379 specifies several key requirements to ensure effective and secure delegated path validation.

Firstly, if a client requests a specific validation policy that the DPV server does not support, the server must return an error. This ensures that the client is aware that the requested policy cannot be applied. If the client does not specify a validation policy, the server must indicate which validation policy was used in the response. This transparency allows clients to understand the basis on which the validation was performed. [1]

Validation policies can be complex and may include parameters such as root self-signed certificates. The DPV protocol must allow clients to include these policy-dependent parameters in their requests. However, it is expected that most clients will either reference a validation policy suitable for their application or accept the DPV server's default validation policy. [1]

Clients can also request that the DPV server determines the certificate's validity at a specific time other than the current time. In such cases, the server must obtain revocation status information relevant to the specified validation time. If the necessary revocation status information is unavailable, the server must return a status indicating that the certificate is invalid, possibly providing additional details about the reason for invalidity. [1]

For the validation to proceed, the certificate must be either directly provided in the request or unambiguously referenced by details such as the CA distinguished name, certificate serial number, and certificate hash. This ensures that the correct certificate is validated. [1]

The DPV client must be capable of providing the validation server with useful certificates and revocation information related to each certificate being validated. This includes OCSP responses, CRLs, and delta CRLs, which are critical for checking the current status of certificates. [1]

The DPV server must have access to the certificate that needs validation. If the certificate is not provided in the request, the server must obtain it and verify that it matches the reference provided by the client. In the response, the server must include either the certificate or a clear reference to it, especially in cases involving CA key compromises. [1]

The response from the DPV server must indicate one of the following statuses: [1]

If the certificate is not valid, the server must also provide the reason for this determination. Common reasons include the inability to construct a certification path, the constructed path failing the validation algorithm, or the certificate not being valid at the requested time, such as before its validity period begins or during a suspension. [1]

Additionally, the DPV protocol must allow clients to request that the server includes extra information in its response. This extra information helps relying parties who do not trust the DPV server to be confident that the certificate validation was performed correctly. The DPV response must be bound to the DPV request, which can be achieved by including a one-way hash of the request in the response. This binding ensures that all request parameters were considered in building the response. [1]

To ensure the client trusts the DPV server, the response must be authenticated. 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. The DPV server's certificate must authenticate the server, adding another layer of trust and security to the validation process. [1]

Relaying, re-direction and multicasting

Application of the DPV framework in TLS-based communications, with the optional use of a relaying mechanism by the primary DPV server. Delegated path validation.png
Application of the DPV framework in TLS-based communications, with the optional use of a relaying mechanism by the primary DPV server.

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. To address this, a DPV server can be configured to leverage the services of other DPV servers. In such scenarios, the client remains unaware that the primary DPV server is utilizing additional servers to fulfill the request. Essentially, the primary DPV server acts as a client to another DPV server, facilitating a more comprehensive validation process. 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. However, it is not expected that DPV clients will support these features. If a protocol incorporates such functionalities, it must also provide mechanisms to ensure compatibility with DPV clients and servers that do not support these advanced features, ensuring adherence to the basic protocol requirements. [1]

Security implications

The DPV protocol must incorporate mechanisms to prevent replay attacks, ensuring that malicious entities cannot reuse validation requests to gain unauthorized access. [1] Importantly, this replay prevention must not depend on synchronized clocks between the client and server, which can be a vulnerability if clocks are not accurately aligned. [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. However, if the certificate is found to be invalid or if the server cannot determine its validity, the server may choose to omit this information to avoid unnecessary disclosure of potentially sensitive details. [1]

The revocation status information used by the DPV server pertains to the validation time specified in the client's request. This validation time might differ from the actual time when the certificate's private key was used to sign a document or transaction. [1] Therefore, the DPV client should adjust the validation time to account for several delays: [1]

By considering these factors, the DPV protocol try to ensure that the revocation status information accurately reflects the current validity of the certificate, enhancing the overall security and reliability of the validation process. [1]

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Certificate revocation list</span> A list of revoked digital certificates

In cryptography, a certificate revocation list (CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted".

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

The certification path validation algorithm is the algorithm which verifies that a given certificate path is valid under a given public key infrastructure (PKI). A path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted certificate authority (CA).

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

The Server-based Certificate Validation Protocol (SCVP) is an Internet protocol for determining the path between an X.509 digital certificate and a trusted root and the validation of that path according to a particular validation policy.

<span class="mw-page-title-main">HTTP 403</span> HTTP status code indicating that access is forbidden to a resource

HTTP 403 is an HTTP status code meaning access to the requested resource is forbidden. The server understood the request, but will not fulfill it, if it was correct.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

An offline root certificate authority is a certificate authority which has been isolated from network access, and is often kept in a powered-down state.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

In public key infrastructure, a validation authority (VA) is an entity that provides a service used to verify the validity or revocation status of a digital certificate per the mechanisms described in the X.509 standard and RFC 5280.

In public key cryptography, a certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker could exploit such a compromised or misissued certificate until expiry. Hence, revocation is an important part of a public key infrastructure. Revocation is performed by the issuing certificate authority, which produces a cryptographically authenticated statement of revocation.

References

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 RFC   3379 (September 2002), chapter 4, Delegated Path Validation and Delegated Path Discovery Protocol Requirements.
  2. 1 2 3 RFC   5280 (May 2008), chapter 6, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
  3. Ma, Zane; Austgen, James; Mason, Joshua; Durumeric, Zakir; Bailey, Michael (2021-11-02). "Tracing your roots: Exploring the TLS trust anchor ecosystem". Proceedings of the 21st ACM Internet Measurement Conference. IMC '21. New York, NY, USA: Association for Computing Machinery. pp. 179–194. doi:10.1145/3487552.3487813. ISBN   978-1-4503-9129-0.
  4. Syverson, P. (1994). "A taxonomy of replay attacks [cryptographic protocols]". Proceedings the Computer Security Foundations Workshop VII. IEEE Comput. Soc. Press. pp. 187–191. doi:10.1109/CSFW.1994.315935. ISBN   978-0-8186-6230-0.

Further reading