PKI Resource Query Protocol (PRQP) is an Internet protocol used for obtaining information about services associated with an X.509 Certificate Authority. It is described by RFC 7030 published on October 23, 2013. PRQP aims to improve Interoperability and Usabilities issues among PKIs, helping finding services and data repositories associated with a CA. Messages communicated via PRQP are encoded in ASN.1 and are usually communicated over HTTP.

Background

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).

In PKIs there are three other primary methods for clients to obtain pointers to PKI data: adopting specific certificate extensions; looking at easily accessible repositories (e.g. DNS, local database, etc.); and adapting existing protocols (e.g. Web Services).

Certificate Extensions

To provide pointers to published data, a CA could use the Authority Information Access (AIA) and Subject Information Access (SIA) extensions as detailed in RFC 3280. The former can provide information about the issuer of the certificate while the latter carries information (inside CA certificates) about offered services. The Subject Information Access extension can carry a URI to point to certificate repositories and timestamping services. Hence this extension allows to access services by several different protocols (e.g. HTTP, FTP, LDAP or SMTP).

Although encouraged, usage of the AIA and SIA extension is still not widely deployed. There are two main reasons for this. The first is the lack of support for such extensions in available clients. The second reason is that extensions are static, i.e. not modifiable. Indeed, to modify or add new extensions, in order to have users and applications to be aware of new services or their dismissal, the certificate must be re-issued.

This would not be feasible for End Entities (EE) certificates, except during periodic reissuing, but it would be feasible for the CA certificate itself. The CA could retain the same public key and name and just add new values to the AIA extension in the new certificate. If users fetch the CA cert regularly, rather than caching it, this would enable them to become aware of the new services. Although this is possible, almost every available clients do not look for CAs certificates if they are already stored in clients' local database.

In any case, since URLs tend to change quite often while certificates persist for longer time frames, experience suggests that these extensions invariably point to URLs that no longer exist. Moreover, considering the fact that the entity that issues the certificates and the one who runs the services may not be the same, it is infeasible that the issuing CA will reissue all of its certificate in case a server URL's changes. Therefore, it is not wise to depend on the usage of AIA or SIA extensions for available services and repositories lookup.

DNS Service Records

The SRV record or DNS Service record technique is thought to provide pointers to servers directly in the DNS (RFC 1035). As defined in RFC 2782, the introduction of this type of record allows administrators to perform operations rather similar to the ones needed to solve the problem PRQP addresses, i.e. an easily configurable PKI discovery service.

The basic idea is to have the client query the DNS for a specific SRV record. For example, if an SRV-aware LDAP client wants to discover an LDAP server for a certain domain, it performs a DNS lookup for _ldap._tcp.example.com (the _tcp means the client requesting a TCP enabled LDAP server). The returned record contains information on the priority, the weight, the port and the target for the service in that domain.

The problem in the adoption of this mechanism is that in PKIs (unlike DNS) there is usually no fixed requirement for the name space used. Most of the time, there is no correspondence between DNS structure and data contained in the certificates. The only exception is when the Domain Component (DC) attributes are used in the certificate's Subject.

The DC attributes are used to specify domain components of a DNS name, for example the domain name example.com could be represented by using the dc=com, dc=example format. If the CA's subject field would make use of such a format, the Issuer field would allow client applications to perform DNS lookups for the provided domain where the information about repositories and services could be stored.

However, currently, the practice is very different. In fact it is extremely difficult for a client to map digital certificates to DNS records because the DC format is not widely adopted by existing CAs. For example, only one certificate from IE7/Outlook certificates store uses the domain components to provide a mapping between the certificate and an Internet Domain.

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.