* Victor Duchovni wrote on Mon, Sep 24, 2007 at 21:05 -0400: > > Whatever you want to call it. The point is, if the client > > can't validate the self-signed cert, you need some other way > > to make sure the server and client have opposite ends of the > > *same* SSL connection, rather than ends of two SSL > > connections to a MITM. A simple way to do this is to compare > > each sides 'finished' with the other side's 'peer finished'. > > No, the challenge is key management. TLS is just fine.
What do you mean, `TLS is just fine'? Doesn't it depend on the requirements? I think, for key management itself (like transferring secret keys), TLS is not suited. TLS AFAIK is limited to one session key (someone could wish one for authentication and a second one for encryption). Also, because of asymetric keys, keys cannot be derived (which would be possible for instance with 3DES keys). Revealing a secret keys can be used to decrypt pre-recorded chiphertext (AFAIK). TLS can be at most as good as the PKI (so in standard PC browsers and the many different CAs that are installed with the many different policies and stuff this probably is not so much). Ohh, and not to forget that the X.509 (just BTW, there even is a v1 :)) subject names are more or less `informal'. Some CA may require a `Ltd' company to contain the `Ltd' in the subject, others may not or may allow to omit the country. Today something like a `Extended Validation Certificate' exist which indicates that there are fun-level-security certificates that can only be used for the same level of SSL strength :-) > If CAs don't solve key management for you, roll your own key > management, but use existing protocols. If for some application (not meaning only a computer program) the "usual" CAs are inappropriate, maybe for this application PKI is not suited at all, could happen. Maybe I missunderstand you, but I think, when SSL/TLS is not suited then it should not be needed, even if with OpenSSL such a nice lib is avialable :) Or do you mean `existing protocols' in general? Like `do not invent your own cryptosystem' to avoid designing weaknesses but favor well-analysed systems? > I would like to see GSSAPI support in TLS (so would Microsoft > and a few others). This addresses key management, without > requiring secondary protocols, and ties into the dominant > standard intra-mural authentication system. This would use a > certificate-less cipher-suite, but the point remains that > authentication should be within TLS, not an add-on. ohh, now I got so many questions :) According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? You said `without requiring secondary protocols', but wouldn't the implementation of that API be nothing else than such a secondary protocol (OCSP or so)? What is meant by certificate-less cipher-suite? A protocol not using certificates, such as SSL without X.509 certificates at all? How would the authentication work? Did I understand correctly that GSSAPI means, that applications do not depend on the implementation (vendor) of some `GSSLIB' but that the applications can `talk' via GSSAPI only to some peer if it uses the same implementation (vendor), because this implementation can use whatever message to transmit tokes? Sorry for my boring noob questions but maybe the one or other could be answered by some URL/link? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
