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

( 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 that
of the RQA.
Security Considerations . The PRQP provides
URLs to PKI resources, therefore it only provides
locators to data and services, and not the real
data. It still remains the client's job to access the
provided URLs to gather the needed data, and
to validate the data (e.g., via signatures or SSL).
Because of this consideration, both the NONCE
and the signature are optional in order to provide
flexibility in how requests and responses are
generated.
Also, it is then possible to provide pre-comput-
ed responses in case the NONCE is not provided
by the client. If an authenticated secure channel
is used at the transport level between the client
and the RQA (e.g. HTTPS or SFTP) signatures
in requests and responses can be safely omitted.
Distribution of RQA addresses. The distribu-
tion of the RQA's address to clients is still an open
issue. There are four possible approaches. A first
option would be to use the AIA and SIA exten-
sions to provide pointers to RQAs. We believe
that by using these extensions in certificates to
locate the RQA, one could provide an easy way
to distribute the RQA's URL. The size of issued
certificates would be smaller than embedding all
the pointers for CA's resources, thus providing a
more space efficient solution.
The second option is applicable mostly for
LANs, and consists of providing the RQA's ad-
dress by means of DHCP. This method would be
mostly used when a trusted RQA is available on a
local network. These two techniques can then be
combined together. Although the service number
for DHCP and DHCPv6 for PRQP have not yet
been assigned by IANA, the official protocol draft
describes how to provide local RQAs addresses
via dynamic host configurations.

The third option—which could be successfully
applied in special-purpose application environ-
ments like Grid Computing—is to embed the
RQA's address directly into application software
distributions. This approach could be adopted
in grids and VOs where a centralized software
distribution system is in place. At each software
update, the RQA network address can be updated
as well. If the distributed software is not digitally
signed by a trusted authority, this approach could
be subject to serious security threats, e.g. distribu-
tion of an altered package by a malicious attacker
where the configured RQAs are not the “official”
ones. Besides the security considerations already
discussed above, the trust level in the application's
RQA configuration should be not less then that put
into browser or operating system certificate stores.
Ultimately, the RQA address can be retrieved
by querying the DNS for specific service records.
The SRV records—or Service records—technique
was meant as a way to provide pointers to serv-
ers directly in the DNS. As defined in RFC 2782
(A. Gulbrandsen, P. Vixie, and L. Esibov, 2000),
the introduction of this type of record allows ad-
ministrators to perform automatic discovery for
local network services. The core idea behind SRV
records is to have the client query the DNS for a
specific SRV record. For example if an SRV-aware
OCSP client wants to discover an OCSP server
for a certain domain, it performs a DNS lookup
for ocsp.tcp.example.com (the “ tcp” means the
client requesting a TCP enabled OCSP server).
The returned record contains information on the
priority, the weight, the port and the target for the
service in that domain.
Although used for many different network-
related configurations (e.g., printing services), this
approach has not been successfully deployed for
PKI-related services. Besides the issues related to
relying on not authenticated services for discover-
ing the network addresses of specific resources,
the main issues are related to the fact that there
is no correspondence between DNS structure
and data contained in the certificates. The only