Public-Key Infrastructures (PKIs) provide a centralized and scalable way to manage trust relationships. In fact, relying parties depend on chains of certificates in order to determine whether or not to accept a given key for a specific purpose. The chains extend from trust anchor points which are directly accepted as reliable. The verification process, then, proceeds through zero or more intermediate CAs till the full chain has been analyzed. Moreover new services and protocols have been developed to facilitate this process, such as OCSP, SVCP or TimeStamping.

Still today PKIs suffer from interoperability issues. To address this problem many different trust models have been proposed such as hierarchies, cross-certification and bridge CAs. Even if each of the proposed models has its own advantages, none addresses supplemental data availability issues efficiently. Most of today end-user applications rely on trust lists, in fact network applications such as browsers or Mail User Agents (MUAs) use them as a base for trust. By including all the certificates into applications is the only way available today, to achieve a sort of interoperability among different PKIs. This approach has several disadvantages (e.g., high costs for CAs to undergo a certification process) and does not solve the problem.

A new approach is needed to provide a flexible way to automatically discover which services and data repositories are available from a CA, e.g. if a cross-certification service exists, where is the entry point, what policies are used, are there mapping matrices available etc. It is to be noted that PRQP will not be aimed at providing another certificate validation service, but to tackle the lack of pointers (URLs) to any services and resources related to PKIs, e.g. an attribute signing service may be facilitated in this way. The PRQP new protocol will equip applications with pointers to where to look for needed PKI resources for path building or data validation.

The Resource Query Authority (RQA) is an Authority which is entitled by a CA to provide answers about provided PKI resources.

In our protocol, an RQA can play two roles. First, a CA can directly delegate an RQA as the party who can answer queries about its certificates, by issuing a certificate to the RQA with a unique value set in the extendedKeyUsage (i.e. prqpSigning). The RQA will provide authoritative responses for requests regardingthe CA that issued the RQA certificate. Alternatively, an RQA can act as Trusted Authority (TA) ("trusted" in the sense that a client simply chooses to trust the RQA's judgment). In this case, the RQA may provide responses about multiple CAs without the need to have been directly certified by them. To operate as a TA, a specific extension (prqpTrustedAuthority) should be present in the RQA's certificate and its value should be set to TRUE. In this configuration the RQA may be configured to respond for different CAs which may or may not belong to the same PKI as the RQA's one.

The Figure shows an example of this protocol: an SSL web server needs to retrieve the revocation status of a user's certificate. (Here, the Web server is the PQRP requesting client.) At first (step 1), the web server receives the user's certificate from the browser. The web server looks at the issuer identifier in the certificate and builds up a PRQP request asking the RQA for the location of the OCSP server of the CA that issued the user's certificate (step 2). The RQA provides (step 3) the web server with the URL of the requested service, as configured on the RQA. In this particular example only the OCSP URL is requested, and therefore only the locator for such service is put in the response. The web server, then, continues with the normal validation procedures (step 4) by using the provided URL to directly access the OCSP server.