You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-c-dev@ws.apache.org by Supun Kamburugamuva <su...@gmail.com> on 2008/06/02 10:35:48 UTC
Encryption and signature with multiple end points
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.
Regards,
Supun.
Re: Encryption and signature with multiple end points
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi all,
In the case that supun mentioned, even clients private key and public key
can be in any other format than files. So in this case we have to provide a
way to specify them also. So it's just like exposing rampart configuration
in policy file as a API.
I think if we are going to provide a way to specify the receiver certificate
in the client side, we must expose other configuration parameters also.
This will give some flexibility, but it will make web services clients more
complicated by moving unnecessary configuration parameters to programming
interface.
Thanks
Milinda..
On Mon, Jun 2, 2008 at 4:34 PM, Supun Kamburugamuva <su...@gmail.com>
wrote:
> On Mon, Jun 2, 2008 at 2:14 AM, Kaushalye Kapuruge <ka...@wso2.com>
> 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.
>
>
> > Cheers,
> > Kaushalye
> >
> > Regards,
> >> Supun.
> >>
> >>
> >>
> >
> >
> > --
> > http://blog.kaushalye.org/
> > http://wso2.org/
> >
> >
>
--
http://mpathirage.com
http://wso2.org "Oxygen for Web Service Developers"
http://wsaxc.blogspot.com "Web Services With Axis2/C"
Re: Encryption and signature with multiple end points
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Mon, Jun 2, 2008 at 5:23 AM, Kaushalye Kapuruge <ka...@wso2.com>
wrote:
> Supun Kamburugamuva wrote:
>
>> On Mon, Jun 2, 2008 at 2:14 AM, Kaushalye Kapuruge <ka...@wso2.com>
>> 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/
>
>
Re: Encryption and signature with multiple end points
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
Supun Kamburugamuva wrote:
> On Mon, Jun 2, 2008 at 2:14 AM, Kaushalye Kapuruge <ka...@wso2.com>
> 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.
Cheers,
Kaushalye
>
>> Cheers,
>> Kaushalye
>>
>> Regards,
>>
>>> Supun.
>>>
>>>
>>>
>>>
>> --
>> http://blog.kaushalye.org/
>> http://wso2.org/
>>
>>
>>
>
>
--
http://blog.kaushalye.org/
http://wso2.org/
Re: Encryption and signature with multiple end points
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Mon, Jun 2, 2008 at 2:14 AM, Kaushalye Kapuruge <ka...@wso2.com>
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.
> Cheers,
> Kaushalye
>
> Regards,
>> Supun.
>>
>>
>>
>
>
> --
> http://blog.kaushalye.org/
> http://wso2.org/
>
>
Re: Encryption and signature with multiple end points
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Mon, Jun 2, 2008 at 4:32 AM, Manjula Peiris <ma...@wso2.com> wrote:
>
> On Mon, 2008-06-02 at 04:15 -0700, Supun Kamburugamuva wrote:
> > On Mon, Jun 2, 2008 at 2:51 AM, Manjula Peiris <ma...@wso2.com> 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.
> > >
> >
> > Please consider this scenario. We have a service and we are accepting
> > messages from different clients (We have fixed number of trusted clients
> > that we need to serve). Most of these clients are not users and they are
> > applications. They have a public/private key pair but do not have a user
> > name. Now all of them are signing and sending there messages with their
> > certificate inside the message. This scenario works as far as nobody
> wants
> > to cheat on us. Now if a unauthorized client wants to access the service
> it
> > can do that easily by sending a message with its certificate embedded in
> the
> > message. We don't differentiate between the authorized client and the
> > unauthorized client since we are using whatever certificate embedded
> inside
> > the message.
>
> This is an authorization problem. So checking the authorization using
> the public certificate is not the correct way. There are some other
> means to handle this. I think if you really want to support this using
> the key store you first need to look at the overhead of this key
> comparison.
AFAIK this is authentication. Authorization is a service specific thing that
cannot be handled by Rampart/C and it has to be handled by the service. For
example a particular client (axis2/C client) may be used by different user
(i.e in a company application all the employees use the same client). But
depending on the user (username/password) these users may have access to
different resource levels.
I think the other way that you are mentioning is username/password. But
usernmae and password is not possible in all the scenarios.
On the other hand in a policy you can specify whether to include the
> certificate or not. So if you really want the authorization using this
> what can be done is specifying not to include the token in your service
> policy. Because people sends their certificates because it is easy for
> receivers not to store each and every certificate. That's why there are
> two mechanisms not to include your certificate and to include the
> certificate in your message.
>
This is another strong reason why we should use this. Instead of sending the
whole certificate we can send an unattached reference and the size of the
message will be considerably reduced.
> >
> >
> > > 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.
> > >
> >
> > AFAIK We don't have to parse the whole certificates to get a match. We
> can
> > use certain attributes of the certificate like issuer serial to check
> > weather we have the certificate in the key store.
> >
> > > >
> > > > 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.
> > > >
> > > >
> > >
> > >
>
>
Re: Encryption and signature with multiple end points
Posted by Manjula Peiris <ma...@wso2.com>.
On Mon, 2008-06-02 at 04:15 -0700, Supun Kamburugamuva wrote:
> On Mon, Jun 2, 2008 at 2:51 AM, Manjula Peiris <ma...@wso2.com> 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.
> >
>
> Please consider this scenario. We have a service and we are accepting
> messages from different clients (We have fixed number of trusted clients
> that we need to serve). Most of these clients are not users and they are
> applications. They have a public/private key pair but do not have a user
> name. Now all of them are signing and sending there messages with their
> certificate inside the message. This scenario works as far as nobody wants
> to cheat on us. Now if a unauthorized client wants to access the service it
> can do that easily by sending a message with its certificate embedded in the
> message. We don't differentiate between the authorized client and the
> unauthorized client since we are using whatever certificate embedded inside
> the message.
This is an authorization problem. So checking the authorization using
the public certificate is not the correct way. There are some other
means to handle this. I think if you really want to support this using
the key store you first need to look at the overhead of this key
comparison.
On the other hand in a policy you can specify whether to include the
certificate or not. So if you really want the authorization using this
what can be done is specifying not to include the token in your service
policy. Because people sends their certificates because it is easy for
receivers not to store each and every certificate. That's why there are
two mechanisms not to include your certificate and to include the
certificate in your message.
>
>
> > 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.
> >
>
> AFAIK We don't have to parse the whole certificates to get a match. We can
> use certain attributes of the certificate like issuer serial to check
> weather we have the certificate in the key store.
>
> > >
> > > 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.
> > >
> > >
> >
> >
Re: Encryption and signature with multiple end points
Posted by Supun Kamburugamuva <su...@gmail.com>.
On Mon, Jun 2, 2008 at 2:51 AM, Manjula Peiris <ma...@wso2.com> 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.
>
Please consider this scenario. We have a service and we are accepting
messages from different clients (We have fixed number of trusted clients
that we need to serve). Most of these clients are not users and they are
applications. They have a public/private key pair but do not have a user
name. Now all of them are signing and sending there messages with their
certificate inside the message. This scenario works as far as nobody wants
to cheat on us. Now if a unauthorized client wants to access the service it
can do that easily by sending a message with its certificate embedded in the
message. We don't differentiate between the authorized client and the
unauthorized client since we are using whatever certificate embedded inside
the message.
> 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.
>
AFAIK We don't have to parse the whole certificates to get a match. We can
use certain attributes of the certificate like issuer serial to check
weather we have the certificate in the key store.
> >
> > 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.
> >
> >
>
>
Re: Encryption and signature with multiple end points
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi all,
Please find my comment inline.
On Mon, Jun 2, 2008 at 3:21 PM, Manjula Peiris <ma...@wso2.com> 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"
Re: Encryption and signature with multiple end points
Posted by Manjula Peiris <ma...@wso2.com>.
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.
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.
> >
> > 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.
> >
> >
>
>
Re: Encryption and signature with multiple end points
Posted by Kaushalye Kapuruge <ka...@wso2.com>.
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.
Cheers,
Kaushalye
> Regards,
> Supun.
>
>
--
http://blog.kaushalye.org/
http://wso2.org/