Hi all, Please find my comment inline. On Mon, Jun 2, 2008 at 3:21 PM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
> > On Mon, 2008-06-02 at 14:44 +0530, Kaushalye Kapuruge wrote: > > Supun Kamburugamuva wrote: > > > Hi List, > > > > > > At the moment a Rampart/C service can handle single client for signed > > > messages. This is because of the static configuration of the > certificate > > > files. Now Rampart/C supports the PKCS12 key stores. A PKCS12 key store > > > allows the service writer to specify multiple certificates. These > > > certificates can be used by the service to verify weather the actual > > > signature is from a trusted user. > > > > > > This is the proposed way of handling multiple clients in the server > side. > > > Service writer has to create a key store with the certificates of all > the > > > trusted parties. A request has a reference to the certificate that it > used > > > for signing. Usually there are various ways to refer an X509 > certificate. > > > > > > First case is to embed the certificate in the message itself. In this > case > > > the reference will be a direct one. Rampart/C will extract the > certificate > > > from the message and checks weather it is in the certificate store. If > it is > > > in the store it indicates that a trusted user has signed the message. > If the > > > certificate is not in the store the request is rejected. > > In this case do we really need to check the key store ? Because message > is signed using sender's private key and he is sending his certificate > to verify. So we need to verify using that and just need to be sure that > the message is integrity protected by the way to the receiver. Even though integrity is verified, how can we sure about requester identity. And we need a way to verify if he is requester has rights to consume the services. This thing also can done using user name token. > > > And if you are going to check whether the certificate is in the store > how are you going to do that? Because from the message you are getting a > relatively big chunk of a string and finding that in the store may be a > time consuming operation. I mean even if you change it to a some other > format there is an unnecessary overhead. We don't have to do much work here. Because we load the certificate using string buffer to verify the certificate and we just need to grab the issuer/serial or thumb print from that certificate and check it inside key store (but this thing will add some overhead). > > > > > > > > > In the second case the certificate is not embedded in the message and a > > > reference to the certificate is sent. In this case the reference will > be > > > used to query the PKCS12 key store and if a matching certificate is > found it > > > will be used to verify the signature of the message. If a match cannot > be > > > found the message is rejected. > > > > > > In both these cases the certificate that is loaded in the in path will > be > > > used for the encryption in the out path. So we are assuming that the > > > response is always going to the end point where the message originated. > > > > > > In the client side the situation is different. Usually a single client > will > > > talk with a single service. So the existing mechanism is enough to > handle > > > most of the cases. But if the client wants to change the certificates > among > > > different requests he should be able to do that. We can easily achieve > this > > > by introducing a new parameter to the rampart client configuration. > > > > > I hope you are trying to suggest a way to a scenario, where a client > > needs to call the "same service" by using different certificates on > > multiple requests. And I'm sorry I do not see a relationship between the > > start of the mail and the end. Are you trying to say that we can achieve > > above requirement using PKCS12? And what the "parameter" you are trying > > to introduce and how exactly that effects the client behavior? > > If it's different services then existing features would be enough I > > guess. Client needs to change bunch of other parameters apart from the > > certificate. > > Cheers, > > Kaushalye > > > > > Regards, > > > Supun. > > > > > > > > > > > I also think that giving user to specify the certificate file is not necessary in this stage. Because we still can do most of the things with current features. From this change only advantage that a user can get is specifying the certificate without modifying the policy files. Also if any one going to specify the certificate, he will need to specify other things also (not only one certificate). Because if we going to give the flexibility to specify a certificate we have to consider about the consistency of the API and make available all other rampart configuration stuffs to dynamically configured. Thanks Milinda -- http://mpathirage.com http://wso2.org "Oxygen for Web Service Developers" http://wsaxc.blogspot.com "Web Services With Axis2/C"
