RFC 3379

Delegated Path Validation and Delegated Path Discovery Protocol Requirements

📅 published September 2002, from ietf

RFC 3379 🎀 Delegated Path Validation and Delegated Path Discovery Protocol Requirements

okay bestie, so this one is from September 2002 and it's an Informational doc, which means it's giving "here's useful info for the internet community" and not "this is an official standard" 💅. It was written by D. Pinkas from Bull and R. Housley from RSA Laboratories ✨. The header doesn't have an Obsoletes or Updates line, so it isn't replacing or changing any earlier RFC. Its whole job is to list the requirements for DPV and DPD, two protocols for checking public key certificates 🔐.

Status of This Memo 📝

This memo gives information to the Internet community 🌐. It does not specify an Internet standard of any kind 🙅‍♀️. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2002). All Rights Reserved 💜.

Abstract 🌸

okay so this doc lays out the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates ✨. It also covers the requirements for managing DPV and DPD policies 📋. literally the whole vibe is "who does the heavy lifting, and what rules do they follow" 🫶.

1. Introduction 🧚

so this doc spells out the requirements for DPV and DPD for Public Key Certificates, and it does it using two main request and response pairs 💖.

delegated processing gives you two main services, DPV and DPD 🔥. some clients need a server to do the whole certification path validation and don't need to go get any data themselves 🙌. other clients only need path discovery so they can do their own local validation 🧠.

the DPV request and response pair can be used to fully hand off path validation to a DPV server 🫡. it follows a set of rules called a validation policy 📜.

the DPD request and response pair lets you get everything you need from a DPD server to validate a certificate on your own device 💅. that includes the end-entity certificate, the CA certificates, full CRLs, delta-CRLs, and OCSP responses 🍓. the DPD server uses a set of rules called a path discovery policy to decide what to send back ✨.

then there's a third request and response pair that lets clients ask a DPV or DPD server for references to the policies it supports 🎀.

1.1. Terminology 💬

here's the important bit about the key words 👑. the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119] 📖. so when you see them in caps, that's the official meaning, no vibes-based interpretation 🙈.

2. Rationale and Benefits for DPV (Delegated Path Validation) 🦋

okay so DPV lets a server do real time certificate validation for a validation time T 🕰️. T can be the current time or a time in the recent past ⏰.

to validate a certificate, you might need a whole chain of certificates, which is called a certification path 🔗. it's made up of the certificate of the public key owner (the end entity), signed by one CA, plus zero or more extra CA certificates that were signed by other CAs 🧶.

offloading path validation to a server might be necessary for a client that doesn't have the processing power or the communication capabilities to fetch the certificates and revocation info, build the certification path, and validate it locally 😭.

in constrained environments like telephones and PDAs, memory and processing limits can make it impossible to implement complete, PKIX-compliant certification path validation [PKIX-1] 📱.

when minimum latency really matters, delegating validation to a trusted server can be a huge win 🏃‍♀️💨. sending the target certificate to the validation server, getting the response, and authenticating that response can take way less time than the client doing path discovery and validation itself ⚡. and even if the client already had the certification path, verifying the signature on each certificate in the path might take longer than the delay from using a validation server, especially with very long paths or a slow processor 🐢.

another reason to offload path validation is that it lets you validate against management-defined validation policies in a consistent way across an enterprise 🏢✨. clients that can do their own path validation might still rely on a trusted server for it if centralized management of validation policies is needed, or they might rely on a trusted server to keep centralized records of those activities 🗂️.

when a client uses this service, it inherently trusts the server as much as it would trust its own path validation software, if it had any 🤝. clients can direct the server to do path validation according to a particular validation policy 🎯.

3. Rationale and Benefits for DPD (Delegated Path Discovery) 🧩

DPD is super valuable for clients that already do most of the PKI processing themselves and just want a server to collect information for them 💁‍♀️. the server is trusted to return the most current information it has access to, which might not be the most current information that has actually been issued 🫠. the client is still the one that performs certification path validation in the end 👑.

a client that does its own path validation can benefit in several ways from using a server to get certificates, CRLs, and OCSP responses [OCSP] as inputs to validation 🍰. here the client is basically relying on the server to talk to the repositories and fetch the data that the client would otherwise have to grab itself using LDAP, HTTP, FTP [LDAP, FTP&HTTP], or some other repository access protocol 📂. these data items are digitally signed, so the client doesn't need to trust the server any more than it would trust the repositories themselves 🔏.

DPD has a bunch of perks 💖. one query to a server can replace multiple repository queries, and caching on the server can cut down on latency ⚡. the client also doesn't need a bunch of different software to talk to different kinds of repositories, possibly over different protocols, and it doesn't need to do the graph processing to discover certification paths on its own, separate from making the queries to get the path validation data 🧠✨.

4. Delegated Path Validation Protocol Requirements 👑

4.1. Basic Protocol ✨

Okay so, the Delegated Path Validation (DPV) protocol lets a server validate one or more public key certificates on behalf of a client, following a validation policy 💅

If the DPV server doesn't support the validation policy the client asked for, then the DPV server MUST return an error. No vibes, just an error 💀

If the DPV request doesn't specify a validation policy, the server response MUST indicate which validation policy was used 🎀

Policy definitions can get super long and complicated, and some policies let you set a few parameters (like root self-signed certificates) 🌸 The protocol MUST allow the client to include these policy-dependent parameters in the DPV request. That said, it's expected that most clients will just reference a validation policy for their app, or go with the DPV server's default validation policy 🫶

The client can ask the server to figure out the certificate validity at a time other than the current time. The DPV server MUST obtain revocation status information for the validation time in the client request ⏰

To get revocation status for any certificate in the certification path, the DPV server might use different sources of revocation information, depending on the validation policy. For example, a mix of OCSP responses, CRLs, and delta CRLs could be used. Or, it could use a response from another DPV server 🧚

If the revocation status information for the requested validation time is unavailable, then the DPV server MUST return a status indicating that the certificate is invalid. Additional information about the reason for invalidity MAY also be provided 🙈

The certificate to be validated MUST either be directly provided in the request or unambiguously referenced, such as the CA distinguished name, certificate serial number, and the hash of the certificate, like ESSCertID as defined in [ESS] or OtherSigningCertificate as defined in [ES-F] 🦋

The DPV client MUST be able to provide to the validation server, associated with each certificate to be validated, useful certificates, as well as useful revocation information. Revocation information includes OCSP responses, CRLs, and delta CRLs. As an example, an S/MIME message might include such information, and the client can simply copy that information into the DPV request 💜

The DPV server MUST have the certificate to be validated. When the certificate is not provided in the request, the server MUST obtain the certificate and then verify that it is indeed the one being unambiguously referenced by the client. The DPV server MUST include either the certificate or an unambiguous reference to the certificate (in case of a CA key compromise) in the DPV response 🔥

The DPV response MUST indicate one of the following status alternatives:

  1. the certificate is valid according to the validation policy.
  2. the certificate is not valid according to the validation policy.
  3. the validity of the certificate is unknown according to the validation policy.
  4. the validity could not be determined due to an error.

When the certificate is not valid according to the validation policy, then the reason MUST also be indicated. Invalidity reasons include:

  • a) the DPV server cannot determine the validity of the certificate because a certification path cannot be constructed.
  • b) the DPV server successfully constructed a certification path, but it was not valid according to the validation algorithm in [PKIX-1].
  • c) the certificate is not valid at this time. If another request could be made later on, the certificate could possibly be determined as valid. This condition may occur before a certificate validity period has begun or while a certificate is suspended.
The protocol MUST prevent replay attacks, and the replay prevention mechanism employed by the protocol MUST NOT rely on synchronized clocks. This one is a big deal, bestie 🚨

The DPV request MUST allow the client to request that the server include additional information in its response. This lets relying parties who don't trust the DPV server still be confident that the certificate validation was done correctly 🔐 That information may (not necessarily exclusively) consist of a certification path, revocation status information from authorized CRL issuers or authorized OCSP responders, revocation status information from CRL issuers or OCSP responders trusted under the validation policy, time-stamp tokens from TSA responders trusted under the validation policy, or a DPV response from a DPV server that is trusted under the validation policy. When the certificate is valid according to the validation policy, the server MUST, upon request, include that information in the response. However, the server MAY omit that information when the certificate is invalid or when it cannot determine the validity 🌈

The DPV server MUST be able, upon request, to copy a text field provided by the client into the DPV response. As an example, this field may relate to the nature or reason for the DPV query 📝

The DPV response MUST be bound to the DPV request, so that the client can be sure that all the parameters from the request have been taken into consideration by the DPV server to build the response. This can be accomplished by including a one-way hash of the request in the response 🔒

In some environments, it may be necessary to present only a DPV response to another relying party, without the corresponding request. In this case, the response MUST be self contained. This can be accomplished by repeating only the important components from the request in the response 🎁

For the client to be confident that the certificate validation was handled by the expected DPV server, the DPV response MUST be authenticated, unless an error is reported (such as a badly formatted request or unknown validation policy) 🫡

For the client to be able to prove to a third party that trusts the same DPV server that the certificate validation was handled correctly, the DPV response MUST be digitally signed, unless an error is reported. The DPV server's certificate MUST authenticate the DPV server ✍️

The DPV server MAY require client authentication, therefore, the DPV request MUST be able to be authenticated 🪪

When the DPV request is authenticated, the client SHOULD be able to include a client identifier in the request for the DPV server to copy into the response. Mechanisms for matching this identifier with the authenticated identity depend on local DPV server conditions and/or the validation policy. The DPV server MAY choose to blindly copy the identifier, omit the identifier, or return an error response 🧾

There are no specific confidentiality requirements within this application layer protocol. However, when confidentiality is needed, it can be achieved with a lower-layer security protocol 🛡️

4.2. Relaying, Re-direction and Multicasting 🦋

In some network environments, especially ones that include firewalls, a DPV server might not be able to obtain all of the information it needs to process a request. However, the DPV server might be configured to use the services of one or more other DPV servers to fulfill all requests. In such cases, the client is unaware that the queried DPV server is using the services of other DPV servers, and the client-queried DPV server acts as a DPV client to another DPV server. Unlike the original client, the DPV server is expected to have moderate computing and memory resources, enabling the use of relay, re-direct, or multicasting mechanisms. The requirements in this section support DPV server-to-DPV server exchanges without imposing them on DPV client-to-DPV server exchanges 🌸

Protocols designed to satisfy these requirements MAY include optional fields and/or extensions to support relaying, re-direction, or multicasting. However, DPV clients are not expected to support relay, re-direct, or multicast. If the protocol supports such features, the protocol MUST include provisions for DPV clients and DPV servers that do not support such features, allowing them to conform to the basic set of requirements 💅

  • When a server supports a relay mechanism, a mechanism to detect loops or repetition MUST be provided.
  • When a protocol provides the capability for a DPV server to re-direct a request to another DPV server (that is, the protocol chooses to provide a referral mechanism), a mechanism to provide information to be used for the re-direction SHOULD be supported. If such re-direction information is sent back to clients, then the protocol MUST allow conforming clients to ignore it.
  • Optional parameters in the protocol request and/or response MAY be provided to support relaying, re-direction, or multicasting. DPV clients that ignore any such optional parameters MUST be able to use the DPV service. DPV servers that ignore any such optional parameters MUST still be able to offer the DPV service, although they might not be able to overcome the limitations imposed by the network topology. In this way, protocol implementers do not need to understand the syntax or semantics of any such optional parameters 👑

5. Delegated Path Discovery Protocol Requirements ✨

okay so the Delegated Path Discovery (DPD) protocol is giving "one stop shop" 💅 The client sends a single request to a single server and gets back, all at once, the data elements that are available right now. That data might normally come from different protocols (like LDAP, HTTP, FTP, or OCSP) or from multiple servers. The point is that the client can locally validate a public key certificate according to one path discovery policy 🎀 The returned information can be used to locally validate one or more certificates for the current time 🫶

Clients MUST be able to specify whether they want, in addition to the certification path, the revocation information associated with the path, for the end-entity certificate, for the CA certificates, or for both. 💖

If the DPD server does not support the client requested path discovery policy, the DPD server MUST return an error. 😭 Some forms of path discovery policy are simple, and in that case it is acceptable to pass the parameters from the path discovery policy with each individual request. For example, the client might provide a set of trust anchors and separate revocation status conditions for the end-entity certificate and for the other certificates 🌸 The DPD request MUST allow more elaborated path discovery policies to be referenced. However, it is expected that most of the time clients will only be aware of the referenced path discovery policy for a given application. 🦋

The DPD server response includes zero, one, or several certification paths. Each path consists of a sequence of certificates, starting with the certificate to be validated and ending with a trust anchor. If the trust anchor is a self-signed certificate, that self-signed certificate MUST NOT be included. 🙈 In addition, if requested, the revocation information associated with each certificate in the path MUST also be returned. ✨

By default, the DPD server MUST return a single certification path for each end-entity certificate in the DPD request. 🧚 However, the returned path may need to match some additional local criteria known only to the client. For example, the client might require the presence of a particular certificate extension or a particular name form. Therefore, the DPD client MUST have a means of obtaining more than one certification path for each end-entity certificate in the DPD request. At the same time, the mechanism for obtaining additional certification paths MUST NOT impose protocol state on the DPD server. Avoiding the maintenance of state information associated with previous requests minimizes potential denial of service attacks and other problems associated with server crashes. 🛡️💜

Path discovery MUST be performed according to the path discovery policy. The DPD response MUST indicate one of the following status alternatives:

1) one or more certification paths was found according to the path
   discovery policy, with all of the requested revocation information
   present.

2) one or more certification paths was found according to the path
   discovery policy, with a subset of the requested revocation
   information present.

3) one or more certification paths was found according to the path
   discovery policy, with none of the requested revocation information
   present.

4) no certification path was found according to the path discovery
   policy.

5) path construction could not be performed due to an error.

When no errors are detected, the information that is returned consists of one or more certification paths and, if requested, its associated revocation status information for each certificate in the path. 🍓

For the client to be confident that all of the elements from the response originate from the expected DPD server, an authenticated response MAY be required. For example, the server might sign the response or data authentication might also be achieved using a lower-layer security protocol. 🔐✨

The DPD server MAY require client authentication, allowing the DPD request MUST to be authenticated. 🤔

There are no specific confidentiality requirement within the application layer protocol. However, when confidentiality is needed, it can be achieved with a lower-layer security protocol. 🫣

6. DPV and DPD Policy Query 🎀

Using a separate request/response pair, the DPV or DPD client MUST be able to obtain references for the default policy or for all of the policies supported by the server. The response can include references to previously defined policies or to a priori known policies. 💅

7. Validation Policy 👑

A validation policy is a set of rules against which the validation of the certificate is performed. 📋

A validation policy MAY include several trust anchors. A trust anchor is defined as one public key, a CA name, and a validity time interval; a trust anchor optionally includes additional constraints. The use of a self-signed certificate is one way to specify the public key to be used, the issuer name, and the validity period of the public key. 🌈

Additional constraints for each trust anchor MAY be defined. These constraints might include a set of certification policy constraints or a set of naming constraints. These constraints MAY also be included in self-signed certificates. ⭐

Additional conditions that apply to the certificates in the path MAY also be specified in the validation policy. For example, specific values could be provided for the inputs to the certification path validation algorithm in [PKIX-1], such as user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, or initial-any-policy-inhibit. 🧠

Additional conditions that apply to the end-entity certificate MAY also be specified in the validation policy. For example, a specific name form might be required. 💖

In order to succeed, one valid certification path (none of the certificates in the path are expired or revoked) MUST be found between an end-entity certificate and a trust anchor and all constraints that apply to the certification path MUST be verified. 🚨

7.1. Components for a Validation Policy 🦋

A validation policy is built from three components:

  1. Certification path requirements,
  2. Revocation requirements, and
  3. End-entity certificate specific requirements.
Note: [ES-P] defines ASN.1 data elements that may be useful while defining the components of a validation policy. 📝

7.2. Certificate Path Requirements 🛤️

The path requirements identify a sequence of trust anchors used to start certification path processing and initial conditions for certification path validation as defined in [PKIX-1]. 🌟

7.3. Revocation Requirements 🔎

Revocation information might be obtained through CRLs, delta CRLs or OCSP responses. Certificate revocation requirements are specified in terms of checks required on the end-entity certificate and CA certificates. 🕵️‍♀️

Revocation requirements for the end-entity certificate may not be the same as the requirements for the CA certificates. For example, an OCSP response may be needed for the end-entity certificate while CRLs may be sufficient for the CA certificates. 💜

The validation policy MUST specify the source of revocation information:

  • full CRLs (or full Authority Revocation Lists) have to be collected.
  • OCSP responses, using [OCSP], have to be collected.
  • delta CRLs and the relevant associated full CRLs (or full Authority Revocation Lists) are to be collected.
  • any available revocation information has to be collected.
  • no revocation information need be collected.

7.4. End-entity Certificate Specific Requirements 🎀

The validation policy might require the end-entity certificate to contain specific extensions with specific types or values (it does not matter whether they are critical or non-critical). For example, the validation policy might require an end-entity certificate that contains an electronic mail address (either in the rfc822 subject alt name or in the emailAddress naming attribute in the subject name). 📧

8. Path Discovery Policy 🗺️

A path discovery policy is a set of rules against which the discovery of a certification path is performed. A path discovery policy is a subset of a validation policy. A path discovery policy MAY either be a reference to a validation policy or contain only some major elements from a validation policy, such as the trust anchors. 🧭

Since the DPD client is "PKI aware", it can locally apply additional selection criteria to the certification paths returned by the server. Thus, a simpler policy can be defined and used for path discovery. 🧁

8.1. Components for a Path Discovery Policy 🍭

The path discovery policy includes certification path requirements, revocation requirements, and end-entity certificate specific requirements. These requirements are the same as those specified in sections 7.2, 7.3, and 7.4, respectively. 🫶

9. Security Considerations ⚠️💀

A DPV client must trust a DPV server to provide the correct answer. However, this does not mean that all DPV clients will trust the same DPV servers. While a positive answer might be sufficient for one DPV client, that same positive answer will not necessarily convince another DPV client. 🚨

Other clients may trust their own DPV servers, or they might perform certification path validation themselves. DPV clients operating under an organizational validation policy must ensure that each of the DPV servers they trust is operating under that organizational validation policy. 🔒

When no policy reference is present in the DPV request, the DPV client ought to verify that the policy selected by the DPV server is appropriate. 👀

The revocation status information is obtained for the validation time. In case of a digital signature, it is not necessarily identical to the time when the private key was used. The validation time ought to be adjusted by the DPV client to compensate for:

  1. time for the end-entity to realize that its private key has been or could possibly be compromised, and/or
  2. time for the end-entity to report the key compromise, and/or
  3. time for the revocation authority to process the revocation request from the end-entity, and/or
  4. time for the revocation authority to update and distribute the revocation status information.

10. Acknowledgments 🌷

These requirements have been refined after some valuable inputs from Trevor Freeman, Paul Hoffman, Ambarish Malpani, Mike Myers, Tim Polk, and Peter Sylvester. 🫶💖

11. References 📚

11.1. Normative References

[PKIX-1]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
           X.509 Public Key Infrastructure Certificate and CRL
           Profile", RFC 3280, April 2002.

[OCSP]     Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
           Adams, "X.509 Internet Public Key Infrastructure Online
           Certificate Status Protocol - OCSP", RFC 2560, June 1999.

11.2. Informative References

okay bestie, these are the extra reads 📚✨ they're informative, not normative, so you don't have to read them, but they're iconic if you want to go down the rabbit hole 🫶

  • [ES-F] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001.
  • [ES-P] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Policies", RFC 3125, September 2001.
  • [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
  • [ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition.
  • [FTP&HTTP] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure. Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
  • [LDAP] Boeyen, S., Howes, T. and P. Richard, "Internet X.509 Public Key Infrastructure Operational Protocols LDAPv2", RFC 2559, April 1999.

12. Authors' Addresses 🎀

meet the two legends who wrote this 💜 here's where you can find them:

Denis Pinkas
Bull
Rue Jean-Jaures - BP 68
78340 Les Clayes-sous-Bois
FRANCE

EMail: Denis.Pinkas@bull.net


Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA

EMail: rhousley@rsasecurity.com

this part is the legal stuff, so the wording stays exactly as written 📜 no remixing this one, bestie 🙈

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 💖

📦 where this page comes from