Also if you embed the signing public cert in the request doesn't that mean you can no longer control which clients have access to your web service? Since if you don't store it, you can authorize clients via the fact that their public cert is stored in your keystore or not.
Or is there a better way to control access to your web service? The only other way I can think of is running your own CA and ensuring the client's public cert is signed by your own CA. Though I can't find docs on how I can setup my own CA. If I could do that I think I'd be comfortable with using the signing public cert to encrypt data back. Thanks in Advance, Richard... > -----Original Message----- > From: Werner Dittmann [mailto:[EMAIL PROTECTED] > Sent: 2005 September 30 1:04 AM > To: Richard Wareing > Cc: 'Abdul Ashik'; 'Apache WSS4J-Dev Mailing List' > Subject: Re: Server Side - Sender Encryption Question > > Richard, > > well, if you spend the effort to maintain all your client's certs > you can do it, but with the help of your Web Service. > > When receiving a request (signed or using UsernameToken) your > web service can determine which client sent it (see some info > in FAQ). Using this information you can setup the name (alias) > to use for encryption (can be done programmatically). If > you do so just don't specify this parameter in the server's > WSDD file. > > Examples how to setup parameters dynamically can be found > in the testcases (test/interop/TestJAXRPCHandler). > > Regards, > Werner > > Richard Wareing wrote: > > Hi Abdul, > > > > > > > > Thanks for the response. The solution looks quite elegant, however > > won't using the useReqSigCert feature on the server's WSDoAllSender > > cause the sender to encrypt using the same public key used to verify the > > requesters signature? I was reading that it is best to use separate > > key-pairs for signing & encryption (Ref: > > http://www.washington.edu/computing/windows/issue22/encryption.html; see > > "Keys, Keys, and More Keys" ). > > > > > > > > That said, what is everyone's experience with this, is it overkill to > > complicate key management for the benefits they cite? > > > > > > > > Regards, > > > > > > > > Richard Wareing > > > > Reimer Technology Group > > > > > > > > > > > > -----Original Message----- > > *From:* Abdul Ashik [mailto:[EMAIL PROTECTED] > > *Sent:* 2005 September 29 2:18 PM > > *To:* Richard Wareing > > *Cc:* Apache WSS4J-Dev Mailing List > > *Subject:* Re: Server Side - Sender Encryption Question > > > > > > > > Hi Richard, > > > > Check out the WSS4J FAQ: > > > > http://wiki.apache.org/ws/FrontPage/WsFx/wss4jFAQ#many > > > > "To perform response encryption set the encryption user name to > > "useReqSigCert". This is a special name that directs the WSDoAllSender > > handler to use the stored client's certificate (the clients public key) > > to perform response encryption." > > > > Cheers, > > Ash > > > > On 9/29/05, *Richard Wareing* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Is there a method of having the client request a particular encryption > > key be used to encrypt the response data? > > > > What I'm trying to do here is have each web service user submit to us > > their public encryption key and use that to encrypt the data back to > > them (in conjunction with signing). In other words, depending on the > > particular user that might be using the web service, we would use a > > specific public key to encrypt data back to them. > > > > Is there a way to accomplish this? > > > > Richard Wareing > > Reimer Technology Group > > > > > > --- > > [This E-mail scanned for viruses by Declude Virus] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --- > [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
