On Mon, Jun 2, 2008 at 5:23 AM, Kaushalye Kapuruge <[EMAIL PROTECTED]> wrote:
> Supun Kamburugamuva wrote: > >> On Mon, Jun 2, 2008 at 2:14 AM, Kaushalye Kapuruge <[EMAIL PROTECTED]> >> 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 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. >>> >>> >> >> >> As I have mentioned earlier our existing infrastructure is enough to >> handle >> the scenario where client always knows who he is going to talk and he has >> the certificate file of the resource provider (Most of the time this will >> be >> the case). But imagine a situation where a client doesn't have the >> receiver >> certificate as a file. In that case he needs to specify the certificate to >> the Rampart/C. The best way to do this is to set the certificate to the >> rampart_config_t in the client side. We don't have to worry about the >> place >> where the client get the certificate. It can be a database, PKCS12 store, >> network call etc. >> >> >> > OK. Now I know where this originated. :-) > Definitely +1 for expanding rampart_config_t. I was confused with the > pkcs12 discussion and the "new" parameter you mentioned. > So Yes... giving client code the flexibility of building configurations is > definitely a good idea. > But even in this case also client must know about the receiving party > (Obvious). The advantage is that Rampart/C doesn't need to worry about the > way that the certificates are stored/specified. > And also I'd like to see a more flexible way of processing key info. Right > now we are processing key information based on standard patterns, those > information can be appeared in a SOAP request. For example the Subject Key > Identifier(SKI). > But note that the specification allows having any information within key > info. For example I can use my NID number with a particular service to > reference my certificate, which is a non-standard way. If the service is > agreed upon a particluar identification that it's clients can abide by, we > should have a way to support it. > So what about having an optional callback for that in the service end? The > primary task of the callback is to process the SOAP header and load the > certificates/keys. +1 for this. This is the generic way of handling things in the service side. If a service writer wants to get the certificates from a LDAP key store or a database this is the only possible way. > Cheers, > Kaushalye > > > > >> >>> Cheers, >>> Kaushalye >>> >>> Regards, >>> >>> >>>> Supun. >>>> >>>> >>>> >>>> >>>> >>> -- >>> http://blog.kaushalye.org/ >>> http://wso2.org/ >>> >>> >>> >>> >> >> >> > > > -- > http://blog.kaushalye.org/ > http://wso2.org/ > >
