Subject: PKI Resource Discovery - Proposal for a new Working Item

From: Massimiliano Pala <[email-masked]>
Date: Thu, 12 Jul 2007 17:29:21 -0400

Hi all,

some times ago I posted a message about a proposal for a PKI Resource Discovery
Protocol ( PRQP ), which I finally formalized and submitted as an I-D.
Unfortunately, because the deadline was already over, it will not probably
published on the ietf archive before the next meeting.

Thanks to all of you who actually helped me and provided useful comments.

At this point we would like to know if the WG would like to take this as
a working item as we really think it could improve the usability and
interoperability of PKIs (especially for isolated PKI islands or in
environments like Grids).

The proposed I-D can also be found here:

   https://www.openca.org/projects/libprqp/docs/draft-pala-prqp-00.html

or here:

   https://www.openca.org/projects/libprqp/docs/draft-pala-prqp-00.txt

I hope there will be time to talk about the proposal at the meeting in
Chicago.

-- 

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: "Anders Rundgren" <[email-masked]>
Date: Sun, 15 Jul 2007 06:56:02 +0200

Hi Max,

In case you find that there is limited interest in PRQP, I encourage
you to explore other avenues in this space.

As the OpenCA Program Manager, I guess you are aware of the fact
that on-line provisioning of certificates is not fully standardized?
One could consider Xenroll a standard since it is supported by 80%
of  the browsers used in PCs.  However,  Xenroll is not supported by
more than a tiny faction of mobile browsers.  The latter is an
interesting target given the 3Bn+ users that will most likely use mobile
phones as their primary, always connected Internet channel.

Theoretically one could distribute keys in SIM cards, but for
practical reasons like operator lock, limited storage, and poor
processing capability, TPMs as defined by TrustedComputingGroup
looks like a better candidate for the universal mobile "key-ring".
Various radio-technologies potentially also open these keys for
desktop usage where the phone becomes a "security device" including
an integrated PIN-code terminal.

Although there is also the [not by MSFT supported] JavaScript method
generateCRMFrequest(), it is actually rather primitive compared to
Xenroll, since only the latter allows multiple passes which can be
quite useful.  In fact, IETF's recently launched KEYPROV activity,
deals with up to four passes (!) for the provisioning of symmetric keys.
I consider the KEYPROV way of doing things superior to Xenroll
and generateCRMFrequest, since it does not expose an API, just a pure
XML protocol giving a uniform user experience and an easier-to-secure
implementation (APIs can be used in many ways, while strictly defined
XML schema-based protocols give little room for misusage).

===============================================
Anyway, I am currently in a _v_e_r_y_ early stage of addressing this
topic and would not mind cooperation with other knowledgeable people.
===============================================

Regarding PRQP, I still feel a little bit puzzled regarding the
resources it is supposed to discover.  A few examples would not hurt.

Regards
Anders

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Thursday, July 12, 2007 23:29
Subject: PKI Resource Discovery - Proposal for a new Working Item

Hi all,

or here:

-- 

Best Regards,

Massimiliano Pala

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 15 Jul 2007 13:00:40 -0400

> Hi Max,

Hello Anders,

> you to explore other avenues in this space.

Well, I am always open to investigate other possibilities. One thing about
PRQP is that some discovery system like this would enable so many new
possibilities in organizing PKIs (and managing them), that I think it
would really ease management of PKIs and adoption of certificates.

> that on-line provisioning of certificates is not fully standardized?

Right, well.. it should be, but it is not yet. Practice is quite far
from being standardized. One thing that really strikes me is that
still today, you mostly need a browser to interact with CAs.

I am also working at an open source PKI-enabling library - which will
be the core of the OpenCA-Ng (Next Generation - where we have to include
support for on-line provisioning of certificates in such a way that
it is easy for the developer to support interactions with the CA
(my assumption here is that, if it is easy for the developer, the
interface will be also easier for the user as the developer will not
simply transfer all the options onto the user because of lack of
knowledge about PKIs).

> phones as their primary, always connected Internet channel.

Right...

> looks like a better candidate for the universal mobile "key-ring".

Well.. if we do not solve the resource discovery and interoperability
between PKIs, then TPMs will always be a nice but unused piece of
HW. I have looked at the TCG work, it is a nice effort, but it is
far from being even usable in closed and controlled environments
(at least for its initial "purpose", i.e., remote attestation).

The only usage of TPM, today, is to provide runtime memory protection
or key storage/usage. And I think it is an easier way to provide some
kind of HW protection for keys.. although... new keys are really stored
in the FS of the hosting machine(..), it is a start...

> desktop usage where the phone becomes a "security device" including
[..]
> XML schema-based protocols give little room for misusage).

Well, in general I am not really a fan of XML + Schema usage for
certificates. Besides the fact that I love XML.. it is easy for the
user... but when it comes to certificates (especially if you take in
consideration small devices and the possibility to have pkis integrated
into them -- e.g., sensors, mobile phones, etc.. ) I would stick with
a more compact message format (DER). This, mainly, because one of the
nice features of XML is the possibility to validate the messages by
using schemas, i.e., the application is freed from the need to check
the message syntax. Anyhow, to do so, you have to provide schemas and
the device should also be capable of verifying the message against the
schema - requiring quite a lot of computational power.

That is why, now, I think XML is not the best choice for PKI operational
protocols. It can be a choice when considering more high-level applications,
but this is just my opinion.

I guess this is the right place to ask for collaboration. We really need
to discuss some of the features that would help PKIs to provide more inter
operable services :) It would be interesting to discuss the topic in detail
and if you can come up with a proposal... one thing we need is to have a
description of the current practices and various options (standardized and
non standardized) we have - so we do not duplicate existing work. I guess
this could be a good starting point.

> resources it is supposed to discover.  A few examples would not hurt.

An example tied to your idea would be the following.

As you said different CAs support different protocols/procedures to provide
certificates to its users. If PRQP is used by a CA, a client could ask which
services are provided -- and the CA could reply with a list of services
supported, e.g., if CMS is supported, an URL could be provided for that.
If web (e.g., Xenroll) is supported, another URL could be provided for
that as well. The client will then contact the URL that is supported.

Another scenario where PRQP could be very useful is for service rollover.
For example if a CA starts with providing CRLs and then it wants to provide
OCSP only because CRLs are too big (e.g., DoD problems with CRLs), the
PRPQ responder can dynamically redirect clients from one service to another.

Another scenario could be adding new servers to existing ones to provide
fall back servers to clients without requiring configuring round-robin or
other more complicated load-balancing DNS-based service.

Well, as I said before, PRQP could really open up new possibilities, that
is the most interesting thing about it, I guess.

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 21 Jul 2007 08:08:37 +0200

Max,

Leaving the provisioning stuff out, I have some comments to your examples
<snip>

>other more complicated load-balancing DNS-based service.

These are valid examples but I feel that PRQP may get competition
from SCVP which if implemented in Outlook and similar e-mail clients
would move these issues to the SCVP responder level where they can
be dealt with much easier.  In fact, SCVP is potentially not only
addressing these problems, but may also eliminate intermediaries
like http://ec.europa.eu/idabc/en/document/2318/5644, since SCVP
allows each organization to centrally manage their own trusted partners;
something which they probably did before PKI came into the picture.

Further advantages with SCVP is that it can efficiently deal with the
kind of PKIs that the financial sector is plotting with; i.e. where you
have to pay for validations, requiring each client having a specific
credential in order to access an OCSP responder.  Moving these
hassles to the server-level make such schemes work also for more
traditional PKI-using applications.

I hope I don't sound too negative but if the primary PRQP target is
secure e-mail, I believe there are way too many protocols out there
trying to make secure e-mail work better, including SCVP, TAMP
and DKIM.  Personally, I doubt that S/MIME will ever be a security
solution for the masses.  According to Cisco, 20000 domains
currently use DKIM which probably means that DKIM has already
eclipsed S/MIME in terms of signed message volume (using DKIM,
messages become signed by default without requiring any action by
the user).

Although PRQP of course could be applied to the server-level,
I believe the need for such a protocol here is less obvious but of
course it would be very easy to implement compared to getting
MSFT and Mozilla implementing a new protocol in their e-mail
clients.  EU's unsuccessful standardization attempts in the area of
on-line signatures indicate that getting vendor support is a close
to an insurmountable hurdle when it comes to standard clients.

Right now it seems that the fate of TAMP is on the table.
Since TAMP is somewhat like a reversed SCVP, I believe this
discussion will take considerable resources from other things.

Regards
Anders

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 22 Jul 2007 16:57:42 -0400

Hello Anders,

thanks for the comments. Anyhow I do not think there is competition
between SCVP and PRQP in the sense that PRQP do not deal with certificate
validation in any way. It provides only addresses to PKI resources.

An SCVP server can actually use PRQP to have a dynamic resource discovery
and to be updates about available services.

Also DKIM/SPFS/etc.. provide a different approach specific for E/Mail and
do not deal with digital certificates (in most cases they just use keys
published in DNS). Again, PRQP is thought to be general, not application
specific. It can be used to improve efficiency of servers (SCVP is a good
example - where does the server find the resources it needs ?), or directly
by clients (e.g., where do I send a revocation request ?)

I am not familiar with the TAMP, but if you could provide some pointers
I'll try to take a look at that.

I hope I addresses your comments, if not, let me know :D

Cheers,
Max

-- 

Best Regards,

	Massimiliano Pala