Re: SSL and non-repudiation (WARNING: contains product plug)
Neil, First of all, thanks for your response. On 24 Nov 99, at 14:02, Neil Costigan wrote: > > > To address the non-repudiation / SSL issue > We at Celo developed, over the OpenSSL libs, a web browser plugin > that allows a web content author to 'demand' that a user digitally sign > (using pkcs7/smime) > some data pushed out from a web server. > > It is envoked by standard plugin activation tag. > The server then gets back via HTTPS POST an s/mime package of the > signed data for verification and (optionally) storage for later > non-repudiation. > > Both software based certificates and a number of smartcard readers / > smart cards are supported. > We're supporting both IE and netscape. Your product seems to be very close to what we're looking for. There're a little (but needed!) point to take in account, though: traffic matters. Data are files (up to 100kb) and comes from the client. Server is Netscape Enterprise Server and this long http posts have caused much trouble. Number of clients is slowly increasing. Uploads concentrate in a very short time interval. It wouldn't be reasonable for our customers to send the data back and then sign them, this would be to double the traffic and some other problems about the application logic would arise. I can think of some workaround involving server side, but then we loose the advantage of choosing an external packaged product instead of developing the solution by ourselves. OTOH, it would be nice to provide the client with a signed confirmation from the server telling them that data have been received. Any ideas? > The majority of current customers are using this to get their customers > to confirm/sign transactions passed through html forms. We use the "file" tag in forms and there's a plugin to validate the file in the client yet, in order to avoid traffic when the data is clearly invalid. BTW, as far as I know, the ActiveCard Reader (we use it) doesn't allow access to more than one application concurrently. We've had many problems with this issue trying to control the reader from a plugin while Navigator is using it to retrieve the stored certificate. > See http://www.celocom.ie for details and a download that one can try > against a test server we run. We'll do it a try. Thanks again. With best regards, -- Nicolás Aragón [EMAIL PROTECTED] Departamento de Proyectos Avanzados Software AG España __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SSL and non-repudiation
Another example is Netscape Form Signing (http://developer.netscape.com/tech/security/formsign/formsign.html). -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, 23 November, 1999 12:39 To: [EMAIL PROTECTED] Subject:Re: SSL and non-repudiation Yep, You need something on the top of SSL to provide some kind of signature. OBI is designed to do just this, however I'm not sure you could call it lightweight as it relies on X.12 EDI standards. It's more aimed at the B2B community, after all, the existing Credit Card schemes in the physical telephone-ordering world for B2C doesn't have any non-repudiation of an order, unless they record the phone call. Cheers, Paul -- Paul Ford-Hutchinson : EMEA eCommerce application security : [EMAIL PROTECTED] OSU-1, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005 Maurice klein Gebbinck wrote: > > Hi all, > > This weekend I read the SSL spec and I am wondering about the following. > Suppose I am a the owner of an e-shop and I have a secure webserver. In > order to make sure that all product orders I get are for real, I require > that clients present a valid certificate during the SSL handshake. > However, since after the handshake SSL switches to an encryption method > based on symmetric keys (right?), it makes no sense to store the > encrypted order of a client in a database, because the client can always > argue that I made up the encrypted order myself (which I can since I > know the symmetric key). The only thing the client cannot deny is that > he has made a secure connection with my webserver, but apart from that > nothing can be proven. > > Is this right, and if yes, is there a way within SSL (openssl) to > provide non-repudiation? It sounds right to me, and certainly SSL was not intended to provide non-repudiation as a service. I'd say, therefore, that if you want non-repudiation, you'd need to add it on top of SSL. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] application/ms-tnef
Re: SSL and non-repudiation (WARNING: contains product plug)
To address the non-repudiation / SSL issue We at Celo developed, over the OpenSSL libs, a web browser plugin that allows a web content author to 'demand' that a user digitally sign (using pkcs7/smime) some data pushed out from a web server. It is envoked by standard plugin activation tag. The server then gets back via HTTPS POST an s/mime package of the signed data for verification and (optionally) storage for later non-repudiation. Both software based certificates and a number of smartcard readers / smart cards are supported. We're supporting both IE and netscape. The majority of current customers are using this to get their customers to confirm/sign transactions passed through html forms. See http://www.celocom.ie for details and a download that one can try against a test server we run. Regards, Neil Costigan Nicolas Aragon wrote: > > Hello, > > > > Is this right, and if yes, is there a way within SSL (openssl) to > > > provide non-repudiation? > > It sounds right to me, and certainly SSL was not intended to provide > > non-repudiation as a service. I'd say, therefore, that if you want > > non-repudiation, you'd need to add it on top of SSL. > > I have a similar problem as Maurice. And I guess that what he's > asking isn't exactly if SSL provides non-repudiation, but if > openssl provides library calls that could help us to implement > it, and if we can use the same keys. I'm outside USA, if it helps. > > Provided openssl is meant to be deployed to the clients, it'd > be great if we don't need to add yet another lib... in our > case, certificates will be stored in "smart cards", that > alse requires some config, and (end users + long installations) > uses to be an explosive cocktail :-( > > Thanks in advance, > > Nico > > -- > Nicolás Aragón > [EMAIL PROTECTED] > Departamento de Proyectos Avanzados > Software AG Spain > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SSL and non-repudiation
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Maurice klein > Gebbinck > Sent: Monday, November 22, 1999 12:20 PM > To: [EMAIL PROTECTED] > Subject: SSL and non-repudiation > > > Hi all, > > This weekend I read the SSL spec and I am wondering about the following. > Suppose I am a the owner of an e-shop and I have a secure webserver. In > order to make sure that all product orders I get are for real, I require > that clients present a valid certificate during the SSL handshake. > However, since after the handshake SSL switches to an encryption method > based on symmetric keys (right?), it makes no sense to store the > encrypted order of a client in a database, because the client can always > argue that I made up the encrypted order myself (which I can since I > know the symmetric key). The only thing the client cannot deny is that > he has made a secure connection with my webserver, but apart from that > nothing can be proven. > > Is this right, and if yes, is there a way within SSL (openssl) to > provide non-repudiation? In the real world no! SSL and TLS is a kind of transport layer security. Non-repudiation needs application specific mechanisms. Regrads Rene -- --- Rene G. Eberhard Mail : [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-repudiation
> This weekend I read the SSL spec and I am wondering about the following. > Suppose I am a the owner of an e-shop and I have a secure webserver. In > order to make sure that all product orders I get are for real, I require > that clients present a valid certificate during the SSL handshake. > However, since after the handshake SSL switches to an encryption method > based on symmetric keys (right?), it makes no sense to store the > encrypted order of a client in a database, because the client can always > argue that I made up the encrypted order myself (which I can since I > know the symmetric key). The only thing the client cannot deny is that > he has made a secure connection with my webserver, but apart from that > nothing can be proven. > > Is this right, and if yes, is there a way within SSL (openssl) to > provide non-repudiation? In a word: No. -Ekr [Eric Rescorla [EMAIL PROTECTED]] PureTLS - free SSLv3/TLS software for Java http://www.rtfm.com/puretls/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-repudiation
Maurice klein Gebbinck wrote: > > Hi all, > > This weekend I read the SSL spec and I am wondering about the following. > Suppose I am a the owner of an e-shop and I have a secure webserver. In > order to make sure that all product orders I get are for real, I require > that clients present a valid certificate during the SSL handshake. > However, since after the handshake SSL switches to an encryption method > based on symmetric keys (right?), it makes no sense to store the > encrypted order of a client in a database, because the client can always > argue that I made up the encrypted order myself (which I can since I > know the symmetric key). The only thing the client cannot deny is that > he has made a secure connection with my webserver, but apart from that > nothing can be proven. > > Is this right, and if yes, is there a way within SSL (openssl) to > provide non-repudiation? It sounds right to me, and certainly SSL was not intended to provide non-repudiation as a service. I'd say, therefore, that if you want non-repudiation, you'd need to add it on top of SSL. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
