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

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Max,

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

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

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