RMD160 with openssl
Hi, I wanted to know the following information about RMD160(ripemd160) in conjunction with openssl. 1) Can we use rmd160 along with ciphers in the calls to SSL_CTX_set_cipher_list() I found that there is no mention of rmd160 in MAC algorithms supported. When we execute ./openssl ciphers -v ALL. It only has support for MD5,SHA etc. 2) Basically I require SSL handshake(SSL_connect) to seamlessly work at the client when the Server (and CA)certificate is signed with ripemd160WithRSA. Also the server should be authenticated successfully. Can we do this using openSSL? Many Thanks in advance. Regards, SS Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RMD160 with openssl
On Thu, Feb 01, 2007, Sheshadri Sreenath wrote: Hi, I wanted to know the following information about RMD160(ripemd160) in conjunction with openssl. 1) Can we use rmd160 along with ciphers in the calls to SSL_CTX_set_cipher_list() I found that there is no mention of rmd160 in MAC algorithms supported. When we execute ./openssl ciphers -v ALL. It only has support for MD5,SHA etc. There are no standard ciphersuites that use RMD160 so none are included. 2) Basically I require SSL handshake(SSL_connect) to seamlessly work at the client when the Server (and CA)certificate is signed with ripemd160WithRSA. Also the server should be authenticated successfully. Can we do this using openSSL? Yes OpenSSL should handle certificates using the RM160 digest algorithm OK. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: crlDistributionPoints in a certificate request
Goetz wrote: I think your security model is broken. A CRL and with that the server clients can download it from is part of the chain of security of the CA. So theses servers must be on (best case) dedicated servers that are specially hardened for this usage. These servers are a (potentially outsourced) part of the CA. So the CA needs this list anyway and can incorperate it into all certificates. Letting the client set the crlDistributionPoints may lead to something like: To check if the security of www.server.net is compromised, go to www.server.net and download the CRL. But if the security of this site is compromised, you can't trust any data you downloaded from it. What you can do is something like: * The CA generates the CRLs. * The CA sends the CRLs to a (fixed) known list of external servers clients can download them from. * On signing the CA incorperates this list of CRL download servers into the certificates. * Clients that want to download the CRL contact one of these servers. The server the client contacts to download the CRL is decided on the client. Bye Goetz Hello Goetz, Thank you for your comments and critics concerning my scenario. I’m analysing and trying to built up this scenario by order of my professor. So “it doesn’t make any sense” is an acceptable result as well ;) --“I think your security model is broken….” In this scenario the CRL shall be kept on the www.server.net. And this server is NOT a part of the CA’s security chain. The CA creates, signs and stores the CRL as usual. But in addition the CA also sends a copy of the CRL to www.server.net, which stores the CRL wherever it wants. (Pushing or pulling the CRL is not important to me.) --“But if the security of this site is compromised, you can't trust any data you downloaded from it.” For this reason the CA has to sign the CRL before sending it to www.server.net. When the site is compromised it won’t publish the current CRL. And a missing up-to-date CRL tells everbody that this site is compromised. I hope this idea is not too strange and I’m not telling to much nonsense ;) So I still have got the problem, that the certificate request shall include the CRL distribution point and that the CA has to “copy” it when signing the certificate without knowing the CRL DP in the forefront. I’m looking forward to get more comments, critics and probably the solution to my problem. Greetings domi -- View this message in context: http://www.nabble.com/crlDistributionPoints-in-a-certificate-request-tf3148251.html#a8749031 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
How is OpenSSL affected by changes to Daylight Saving Time (DST) in 2007?
Hi All, I have one question. How is OpenSSL affected by changes to Daylight Saving Time (DST) in 2007? - Durga Prasad Jammula webpage : http://durgaprasad.wordpress.com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Newbie question
Unfortunately, I don't control the server and don't believe there is an SSL connection to that component, but other components will require an SSL connection. So using SSL for everything is not possible. Doug -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bertram Scharpf Sent: Wednesday, January 31, 2007 7:44 PM To: openssl-users@openssl.org Subject: Re: Newbie question Hi, Am Mittwoch, 31. Jan 2007, 13:02:13 -0500 schrieb Doug Kunzman: Can openssl be used for HTTP communication without using SSL if in the future we are going to SSL communication to our project? You should consider using SSL right from the start. There are loads of key generation howtos on the web. I'm running Apache on Gentoo here and it worked right from the start. Just say openssl s_client ... instead of telnet ... on the client side. I experienced handling sensitive data comes earlier than you might reckon and it's no mistake to be prepared in time. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: crlDistributionPoints in a certificate request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 domi wrote: Goetz wrote: I think your security model is broken. A CRL and with that the server clients can download it from is part of the chain of security of the CA. So theses servers must be on (best case) dedicated servers that are specially hardened for this usage. These servers are a (potentially outsourced) part of the CA. So the CA needs this list anyway and can incorperate it into all certificates. Hello Goetz, Thank you for your comments and critics concerning my scenario. I’m analysing and trying to built up this scenario by order of my professor. So “it doesn’t make any sense” is an acceptable result as well ;) In the security context (and especially with certificates) the question is not Is it possible to do something ? but it is Is it adviseable to do something ? What do you gain ? What risks do you get ? --“I think your security model is broken….” In this scenario the CRL shall be kept on the www.server.net. And this server is NOT a part of the CA’s security chain. The CA creates, signs and stores the CRL as usual. But in addition the CA also sends a copy of the CRL to www.server.net, which stores the CRL wherever it wants. (Pushing or pulling the CRL is not important to me.) The crlDistributionPoints extension (roundabout) says: I (the CA) declare that certificates issued by me can be verified with CRLs that can be loaded from the following addresses:... The server MUST in some way be part of the CA infrastructure. It MAY be a server that is not at the same location than the CA is. --“But if the security of this site is compromised, you can't trust any data you downloaded from it.” For this reason the CA has to sign the CRL before sending it to www.server.net. When the site is compromised it won’t publish the current CRL. And a missing up-to-date CRL tells everbody that this site is compromised. Only in your context. In general it only says that there is (at the moment) no CRL available. Imagine the following situation: For some reason the CA is unable to issue a new CRL. (Administrator forgot the passphrase, network connection to CA is down, CA is on fire, a plane crashed into the CA,...) With the moment the last CRL expires all sites the CA issued certificates for become compromised (in the eyes of the clients). I hope this idea is not too strange and I’m not telling to much nonsense ;) In general: It is definitively a bad idea to let the client set a crlDistributionPoints extension with data from the request. The client may only set a very small subset of the possible extensions in a certificate. The subjectAltName extension would be a possible extension the client may set in the request. Guys/Girls: Any other idea what the client may set ? So I still have got the problem, that the certificate request shall include the CRL distribution point and that the CA has to “copy” it when signing the certificate without knowing the CRL DP in the forefront. What you can do is to generate the extension section in the openssl config on the fly with the crlDistributionPoint extension parsed from the request. This will require a small script and no change of the openssl binary. But again: do this only if you really know what you are doing and only after a carefull analysis of the security requirements of the special situation. As far as I see it: + storing CRLs on each server reduces load on the CA infrastructure. But: * CRLs need only to be loaded once in the lifetime of a CRL and this lifetime should be in the range of days * as long you aren't operating a big CA CRLs are small so the load is small. If the lifetime of the CRL is shorter than a day or CRLs become big you need something like OCSP. - - assuming a server is compromised if it hasn't an actual CRL will invalidate all certificates the moment the CA can't generate and distribute the CRLs to the servers. Bye Goetz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFwiB12iGqZUF3qPYRArKgAJoCrS/ruxsacM9j8eOoJBLfiAPnigCdHNDl Cmo/qYhrX+0kvF/XdBIWDtU= =AXIJ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
