On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote: > > Thanks everyone for the SSL encouragement. I'm going to have a quick > re-read of Eric's book over the weekend and then start thinking about > what sort of "easy to use" implementation I could do. I was thinking of > doing a C++ implentation with classes and templates and stuff. (By > contrast OpenSSL is a C implementation). Anyone got any thoughts on
A C++ implementation will be much less useful to many potential users; perhaps the most underserved set of potential SSL/TLS users is in the embedded space, and they often can't afford to, or won't, carry a C++ runtime around with them. We learned this lesson with FreSSH and threads. I would strongly recommend a C implementation with an optional C++ interface, if C++ is the way you want to go. Also, I'd consider, for simplicity's sake, at least at first, implementing *only* TLS, and *only* the required ciphers/MACs (actually, using others' implementations of the ciphers/MACs, even the OpenSSL or cryptlib ones, is probably not just acceptable but actually a _really good idea_.) The major problems with OpenSSL are, from my point of view, caused by severe overengineering in the areas of: 1) Configuration 2) ASN.1/X.509 handling 3) Tightly-coupled support for the many diverse variants of SSL/TLS. As far as what OpenSSL does, if you simply abandon outright any hope of acting as a certificate authority, etc. you can punt a huge amount of complexity; if you punt SSL, you'll lose quite a bit more. As far as the programming interface goes, I'd read Eric's book and then think hard about what people actually use SSL/TLS for in the real world. It's horrifying to note that OpenSSL doesn't even have a published interface for a some of these operations. For example, there is no simple way to do the most common certificate validation operation: take a certificate and an optional chain, and check that the certificate is signed by an accepted root CA, or that each certificate in the chain has the signing property and that the chain reaches that CA -- which would be okay if OpenSSL did the validation for you automatically, but it doesn't, really. >From my point of view, a _very_ simple interface that: 1) Creates a socket-like connection object 2) Allows configuration of the expected identity of the party at the other end, and, optionally, parameters like acceptable cipher suite 3) Connects, returning error if the identity doesn't match. It's probably a good idea to require the application to explicitly do another function call validating the connection if it decides to continue despite an identity mismatch; this will avoid a common, and dangerous, programmer errog. 4) Provides select/read operations thereafter. Would serve the purposes of 90+% of client applications. On the server side, you want a bit more, and you may want a slightly finer-grained extended interface for the client, but still, you can catch a _huge_ fraction of what people do now with only the interface listed above. Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]