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 PRQPD package is aimed to provide a PRQP server and client. It can be used by applications in order to discover PKI services and repositories. The basic concept of the protocol is to provide a method to answer to the question "where is service X URL from this CA ?". The protocol envisages the presence of an Authority, called Resource Query Authority (RQA) which is entitled to provide such data from the CA itself. The following Figure sketches the protocol aim:

In PQRP, the client and the Resource Query Authority (RQA) exchange a single round of messages:

• the client requests a resource token by sending a request to the server;
• the server replies back by sending a response to the requesting entity.

The client embeds zero or more resource identifiers (OIDs)-when specifying exactly the data the client is interested into-in the request token, in order to specify which subset of CA resources she wants. If the client do not specify any services by providing an empty list of OIDs in the request, all of the available data for a particular CA should be returned by the server in the response. The resources might be items that are (occasionally) embedded in certificates today-such as URLs for CRLs or OCSP or SCVP-as well as items such as addresses of the CA homepage address, the subscription service, or the revocation request. Read More...

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.