Subject: PRQP Demo

From: Massimiliano Pala <[email-masked]>
Date: Mon, 03 Dec 2007 21:32:45 -0500

Hi all,

because of issues with the schedule (thanks Stefan for letting me use your
time :D) I had not time to show a demo of the PRQP. Anyhow if you are
interested, just go to the following URL:

	http://rqa.openca.org/prqp

I attach three demo certificates that can be used to query the Resource
Query Authority (RQA):

* Dartmouth-Root.cer and OpenCA-Demo.cer have been actually configured on
   the RQA and responses will carry the specified pointers. The OpenCA-Demo.cer
   CA configuration is the more rich and will provide (fake) pointers to
   services like webcertDav, cmsGateway or trustAnchors.

* EuroPKI-Root.cer has no configuration on the RQA and the provided response
   will carry a "CA Not Present" in the PKIStatus field

Please regard the fact that the web interface to the server is just for
Demo purposes, and it might not be very stable :D

There is also a 'Contribute' section where you can post info about your CAs.
This would help us to setup a demo service which carries information about
many CAs - thus making it more interesting.

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

---

From: Leif Johansson <[email-masked]>
Date: Tue, 04 Dec 2007 19:36:26 +0100

> interested, just go to the following URL:

Thanks Massimiliano,

I have a question though: How are clients supposed to find PRPQ-servers?

This seems to be a special case of the problem of finding resources
associated with
a "name" which was the reason behind RFC3401-3405.

Perhaps it is difficult to see how to normalized names used in DNs but
in the case
when there are subjectAltNames in the cert containing some managed
namespace
then a DDDS would allow you to locate metadata about the cert w/o
resorting to
a well-known-service.

    Cheers Leif

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 04 Dec 2007 11:55:40 -0800

Hello Leif,

coming to your question about how clients are supposed to find PRQP servers,
this is still an open problem. The current proposal deal with the standardization
of the messages. Actually we use HTTP as a suggested transport protocol, but
messages are not dependent on it, therefore if thought to be useful, we could
add other transport mechanisms (e.g., email, ftp, etc.. ). At the moment we
are not addressing this aspect.

To find the Resource Query Authority's address we envision several possibilities.

A naive option is to include the AIA and SIA extensions to carry the pointer
to the RQA directly in digital certificates. This approach works if the CA of
the target certificate provides an RQA.
The extension contents would point to the available RQA and the client could
directly discover services provided by the CA by querying the RQA. This seems
to be in contrast with our idea of providing a dynamic approach because, in
this way, we rely on an extension in the certificate. However, including only
one URL in the certificate that will provide a gateway to find all the other
services provided by one or more CAs is not too constraining.

However, today we could not rely on the presence of RQA pointers in certificates,
yet. Especially when it comes to CA certificates that will last for the next
10 years.

We needed a way to provide clients with a pointer to a local RQA to query for
resources provided by CAs that do not have RQAs.
In fact if no RQA address is present in the certificate, a client application
could use a default configured one.

We have investigated the possibility to use network-level configuration tools
for this purpose. The DHCP protocol provides sufficient flexibility to fulfill
our need. In particular it allows the client to request the server to send
specific information if needed.

By modifying the configuration (to add specific options both to the client and
the server) it is possible to store the provided addresses in a system-wide
configuration file where applications could retrieve the local RQA address.
For example, on the Demo machine we use a configuration file `/etc/pki.conf`
where the information about RQAs addresses are kept.
Here it is an example configuration file for PRQP:

	; Configuration of RQAs for PRQP
	queryauthority	mm.cs.dartmouth.edu
	queryauthority	rqa.openca.org
	queryauthority 	localhost

In case no DHCP server is available, configuration can be provided by using a
simple user interface, also common practice for DNS configuration on many systems.

Coming more specifically to your references to RFC3401-3405, I do not see
how those apply here. As I told in my presentation (and I guess it is
clearly stated in the slides as well), PRQP as it is now is *NOT* a
Discovery System. It can be used by a discovery system to provide discovery
of PKI resources, but the proposal do not try to address this aspect.
Anyhow, our problem is more specific than "finding resources associated
with a name", because we are addressing "finding resources associated with
a CA" that, roughly, can be translated to "finding resources associated
with a [CA] certificate". Names can be ambiguous (at least it is not a
good identifier in PKIX), certificates are not. To be honest, we also
allow the client to ask for resources by identifying the CA certificates
by means of DNs + Serial --- which we know it can be ambiguous. Anyhow
the response from the server (in the new version of PRQP) includes the
appropriate data structures to uniquely identify the [CA] certificate the
services are associated with. Keep in mind that in the design of this
protocol, I tried to have some basic principles: ease of use (from both
a user and developer perspective) and simplicity (trying not to sacrifice
security in the process... ).

I guess that a different proposal, that may use PRQP, should be written
to address the discovery problem --- and it is part of the work I'd like
to address once the PRQP has been sufficiently discussed and analyzed by
the PKIX community. Hopefully we'll have enough people contributing to the
idea so that every weakness will be addressed. One piece at a time :D

I hope I addressed your question, if you have any other doubt and/or
comments, please let me know. If I did not, can you provide examples on
how PRQP and RFC3401-3405 are related ?

Thanks for the comment :)

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 04 Dec 2007 14:42:27 -0800

Hi,

thanks for the reply. I understand it more clearly now. I will look at
the possibility to use the DDDS idea to locate PRQP. The basic problem
(and part of the reason I started the PRQP work) is that there is no
name space in the certificates, now, that we can use. That is why mapping
to DNS, for example, does not work in many cases.

For example if I get a certificate from Verisign and I have in my
subjectAltName field [email-masked], where shall I look for the RQA ?
It is a pain! There is not 'global' solution that would work for
every and each case.

My personal idea, actually, and I already started some work on this, is
to use a more distributed approach. Indeed after the definition of the
PRQP, I am envisioning to use a P2P overlay network to publish all the
information about CAs. You then would need to know just one of those
RQAs in order to 'discover' services associated with any of the
participating CAs.

Thanks for the pointer :) And if you'd like to participate in the work,
please let me know! The more the brains, the better!

Later,
Max

Leif Johansson wrote:
> No :-) My suggestion was that you use DDDS to locate PRPQ servers
> based on the presence of domain-names in altnames in certs. If you
> say "just use AIA/SIA for PRPQ"  then you have just moved the
> problem.
> 
> If the problem is "find resources for *existing* certificates" then you
> either wind up with a (list of) well-known-service points (for PRPQ or
> something similar) or a discovery service (possibly resulting in
> pointers to PRPQ-servers) based on a managed namespace *already*
> present in the certificates issued by deployed PKIs.
> 
> I agree that PRPQ is not a discovery service, I just mean that it won't
> be useful without a discovery service.