Federated PKI Authentication in Computing Grids - Cloud, Grid and High Performance Computing: Emerging Applications - page 173

such a CA operator based upon their own assess-
ment of trustworthiness of the CA. In order for
the relying party to make a local trust decision,
they should consider the statements by the CA
published in their CP and CPS and also review
any other relevant security or trust-related docu-
mentation. Currently this information is gener-
ally not readily available to a relying party from
the CA's certificate, nor can a relying party or
potential subscriber easily find the URI for the
application or revocation of credentials from such
CAs. A mechanism for publishing and updating
this information would greatly enhance the flex-
ibility, and usability of potential grid PKIs. The
PRQP is a perfect candidate for providing such
functionality.

Query Protocol (PRQP) 1 to provide pointers to
any available PKI resource from a particular CA.
The PRQP (M. Pala, 2008) has been already
discussed in the IETF PKIX working group. The
updated version of the PRQP specification, which
includes grid-specific enhancements proposed in
this paper, is published as an Experimental-Track
Internet Draft. In PRQP, the client and a Resource
Query Authority (RQA) exchange a single round
of messages where 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 can request the address of one or
more specific services by embedding one or more
Object Identifiers (OIDs) into the request. The
resources might be items that are (occasionally)
embedded in certificates today—such as URLs
for CRLs, OCSP, SCVP or CP/CPS locations-
--as well as other items, such as addresses for
the CA website, the subscription service, or the
revocation request.
Alternatively, the client may ask for the loca-
tion of all the services provided by a CA by not
specifying any identifier in the request.
The Resource Query Authority. In PRQP,
the server is called the Resource Query Authority
(RQA). An RQA can play two roles. First, a CA
can directly delegate an RQA as the party that 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
regarding the 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 recommendations and
assertions). In this case, the RQA may provide
responses about multiple CAs without the need
to have been directly certified by them.
In this case, provided responses are referred
to as non-authoritative , meaning that no explicit
trust relationship exists between the RQA and
the CA. To operate as a TA, a specific extension

INTEROPERABLE GRID
PKIS: FIRST STEPS

Effective authentication frameworks that make use
of certificates potentially require many different
services such as OCSP servers, CRL repositories,
or timestamping to validate certificates issued by
accredited CAs. As a consequence, certification
authorities need to be able to provide these ser-
vices and to enable applications to discover them.
Because the need to distribute PKI related
data and pointers to services is of primary con-
cern in grids, each grid environment defines its
own specific format and solution. Although this
might temporarily solve specific issues within a
specific grid community, it does not encourage
the exchange of information and interoperability
with other organizations.
It is to be noted that because of the customized
nature of current solutions, specific extensions to
applications must be developed in order to be able
to operate in such environments.
The PKI Resource Discovery Protocol.
The notion of a discovery protocol for PKIs first
appeared in our earlier paper (M. Pala and S. W.
Smith, 2007), which proposed the PKI Resource