At present, ever more services and protocols are being defined to address different needs of users and administrators in PKIs. With the deployment of new applications and services, the need to access PKI resources provided by different organizations is critical. Each application needs to be told about how to find these services for each new certificate it encounters. Therefore, each application needs to be properly configured by filling in complex configuration options whose meaning is mostly unknown to the average user (and likely to the administrator as well).

A dynamic method capable to provide more timely information about provided services and available PKI resources would be interesting. It would also help in painless rollover between services, e.g. switching from CRLs to OCSP for certificate validation. For instance this would allow PKI management to dynamically choose which services are to be provided based on the faced challenges during infrastructure deployment. We believe that a DNS for PKI resources is something that is missing in current deployments and would be most beneficial to, and welcomed by PKI operators and relying parties.

To address interoperability and trust building issues among separate PKI islands we present a new PKI Resource Query Protocol (PRQP).

• 22.07.2007 The PRQP has been published as a new I-D and it is now available from IETF.
• 18.07.2007 The PKI Resource Discovery Protocol (PRQP) will be presented at the 69th IETF Meeting in Chicago during the PKIX WG session. The proposal is to have the PKIX WG to take PRQP as a new working item.
• Internet Draft Proposal for PKI Resource Discovery Protocol Posted here
• Added library documentation Docs and FAQs section.
• Initial source code snaps are available from the download section.

The LibPRQP package is aimed to provide a PRQP enabling library which 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...