Jill Ramonsky wrote: > First, the primary design goal is "simple to use".
This is the highest goal of all. If it is not simple to use, it misses out on a lot of opportunities. And missing out results in less crypto being deployed. If you have to choose between simple-but-incomplete, versus complex-but-complete, then choose the former every time. Later on, you can always upgrade - or the programmer using the system can upgrade - to the full needs if they have shown themselves the need for the complete solution that you optimised away. On these lines, I'd suggest something like: 1. select one cipher suit only, and reject the rest. Select the strongest cipher suit, such as large RSA keys / Rijndael / SHA-256 or somesuch, so there are no discussions about security. 1.b, means basically do TLS only. Don't offer any fallback. If someone is using your protocol, they can select it to talk to their own apps. If someone has to talk to another app using TLS or SSL, then they almost certainly have to talk all suites, so they are more or less forced to do OpenSSL already. Hence, almost by definition, you are forced into the market where poeple don't want to negotiate cipher suites, they want the channel product between their own apps up and running with no fuss. 2. Notwishtanding 1. above, leave the hooks in to add another cipher suite. You should really only plan on one or two more. One for embedded purposes, for example, where you really push the envelope of security for slower devices. And another because someone pays you to do it :-) 3. Ditch Anon-DH as a separate suite. Concentrate on pure certificate comms. Never deviate more than briefly from the true flavour of the tools you are working with. 4. Ignore all complex certificate operations such as CA work, etc. If someone wants that order of complexity, then they want OpenSSL, which includes most of those tools. 5. To meet the dilemma posed by 3, 4, generate self-signed certificates on the fly. Then, the protocol should bootstrap up and get running easily. SSH model. Anyone who wants more, can replace the certs with alternately named and signed certs, as created with more specialised tools. Or they can help you to write those parts. Good protocols divide into two parts, the second part of which starts "trust this key totally." Ignore the first part for now, being, how you got the key. 6. Pick a good X.509 / ASN1 tool. Don't do that part yourself. See all the writings on how hard this is to do. If you want to join the guild of people who've done an ASN1 tool and can therefore call it "easy", do so, but tell your family you won't be home for Christmas :-) 7. Produce a complete working channel security product before going for first release. Nothing slows down progress than a bunch of people trying to help build something that they can't agree on. Build it, then ask for help to round it out. 8. What ever you do ... try and work on the code that is most beneficial for other reasons. Don't plan on completing the project. In the event that you don't complete, make sure that what you did do was worthwhile for other reasons! 9. Take all expert advice, including the above, with some skepticism. You will have much more intuition because you will be deep in the issues. > With that in mind, I believe I could do a safer > implementation in C++ than I could in C. Go with it, then. Being right means you win, being wrong is an opportunity to learn :-) > ... /Of course/ one should be > able to communicate with standard TLS implementations, otherwise the > toolkit would be worthless. Is that the case? I wide variety of uses for any protocol are application to same application. The notion of client-to-server is an alternate, but it's only an alternate. It is not a given that apps builders want to talk to other TLS libs. TLS is there to be used, as is all other software and standards. It is at your option whether you wish to join the group of people that can express comms in *standard* TLS, talking heterogeneously. > (1) THE LICENCE > > I confess ignorance in matters concerning licensing. The basic rules > which I want, and which I believe are appropriate are: > (i) Anyone can use it, royalty free. Even commercial applications. > (ii) Anyone can get the source code, and should be able to compile it to > executable from this. > (iii) Copyright notices must be distributed along with the toolkit. > (iv) Anyone can modify the code (this is important for fixing bugs and > adding new features) and redistribute the modified version. (Not sure > what happens to the copyright notices if this happens though). Sounds like BSD-2 clause or one of the equivalents. The only question I wasn't quite sure of was whether, if I take your code, and modify it, can I distribute a binary only version, and keep the source changes proprietary? If so, that's BSD. If not, you need some sort of restriction like Mozilla (heading towards GPL). My own philosophy has always been that crypto has enough barriers on it already, so it should not add any more personality quirks than necessary, hence preference for BSD two clause. Mind you, such a statement is a personality quirk, so you be your own judge. (Also, bear in mind that you - as owner of your code - have the choice of issuing it under many licences. There is nothing technically wrong with you issuing it under PD, BSD, Mozilla, GPL. It might make things confusing for your user base, but you can do it. It's your code (as long as it *was* your code :-) The corollary to this is that you don't need to decide up front, it can change as time goes on, at the cost of some confusion.) > (2) THE NAME > Anyway, all suggestions welcome. I guess you disposed of SSL-easy. J-TLS? Jill-T might work if you are brave, and like strong cola :) "Jilt" has a ring to it. Names are really hard. I'd defer that one until it pops out. > Pretty Good TLS/SSL... I think I recall the PGP Inc company having trademarked "Pretty Good". Q: Does your employer have any say or comment on this project? Might be wise to clear up the posture, and either get it in writing, or make the repository public from the git-go. Many an open source project has foundered when the boss discovered that it works... > (3) MULTIPLY SIGNED CERTIFICATES > > A technical question now. (I did look at RFC2246 before asking this, but > didn't find the answer there). In GPG / PGP, one can have multiply > signed certificates. It's not called a "certificate" in GPG, it's called > a signed key, but the priniciple is the same. Alice can get her key > signed by both Carol and Dave, which has the intended meaning that both > Carol and Dave vouch for the authenticity of Alice's key. Thus, if Bob > wishes to send to Alice, he can do so provided he trusts /either/ Carol > /or/ Dave. > > Can you do this with X.509 certificates? I know it would be hideously > unusual (not to mention expensive) to get a single certificate signed by > both Verisign and Thwarte, but can it be done? Is it possible? Is it > allowed? I don't believe it is possible to multiply-sign x.509 certs. This is one of the reasons that PKIs based on x.509 have a miserable record, as the absence of any web of trust support and the promoting of a hierarchical trust model goes against most business and individual practices. That said, having chosen TLs, you've chosen x.509 certs (with some caveats). This is the reason why concentrating on self-signed certs is such a clean idea, it neatly avoids the issues of trust models, be they broken or not. OT3H, I suppose you could do TLS-sans certs, which would make for an interesting project, not to mention a lot of time spent justifying your choices :-) But, what's the point to the question? I'm not quite sure how this relates to the essential question of implementing TLS? iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
