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 Anders Rundgren wrote:
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.
--
Best Regards,
Massimiliano Pala
--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] pala@xxxxxxxxxxxxxxxx
project.manager@xxxxxxxxxx
Dartmouth Computer Science Dept Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063 Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature