Anders Rundgren wrote:
Hi Max,
Hello Anders,
In case you find that there is limited interest in PRQP, I encourage 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.
As the OpenCA Program Manager, I guess you are aware of the fact 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).
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.
Right...
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".
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...
Various radio-technologies potentially also open these keys for desktop usage where the phone becomes a "security device" including
[..]
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).
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.
=============================================== 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. ===============================================
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.
Regarding PRQP, I still feel a little bit puzzled regarding the 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
--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