Hi Steve, Sorry that there are loose ends. It's a massive project and at about 80% I had to go back to paying work.
zauth, zcert, and zcertstore form a package, you can understand, use, and improve them together. They implement a specific ZAP handler design based on simple text encoded certificates. It's not a great scheme and there's been a lot of discussion on better certificate formats... which leads nowhere. I had planned and will still someday write a guide to using this authentication layer. However for today what you have is the C code in CZMQ, the examples, and test cases. It is complex because of the unavoidable number of moving pieces. I've tried to avoid inventing random concepts, though. You are required to distribute public and secret keys yourself. The idea is to generate these as text files and then safely install them on clients and servers. CZMQ provides the server-side support for using them at runtime for authentication, though I don't think we covered how to use them for actual socket configuration. Like everything we do, it has to be driven by use and organic growth. So my advice is to treat CZMQ as something _we_ make together, find areas where you want to improve, and send us pull requests. Many thanks for the comments. - Pieter On Thu, Apr 3, 2014 at 1:50 AM, Steve Murphy <[email protected]> wrote: > OK, I've read the man pages for zcert, zcertstore, and zauth. > I've read the tutorial about the wood, stone, and iron houses. > I've compiled those examples, and run them, shoot, I even > wiresharked the ports and captured the conversations to see > the unencrypted vs. encryped communication. Cool. > > But now, it's time to actually write up some code and use this > stuff in a real set of distributed applications, and I find the > docs very frustrating. > > Firstly, little to no explanation in zauth about curve parameters > "domain" and "location", and how to use them. > > Nextly, zcert gives us zcert_new_from(..) which takes byte* args, > but no zcert_new_from_txt(...) with char* args. > > The zcertstore manpage says "To actually create certificates on disk, > use the zcert_class in code, or the tools/makecert.c command line > tool, or any text editor." That's nice, but the only tool in zeromq-4.0.x is > tools/curve_keygen, and it doesn't create a file, > it just prints out the keys with some explanatory text, not even > in cert file format. > > The zmq_curve_keypair example code shows a call to "crypto_box_keypair" > instead of zmq_curve_keypair, which I assume is > a typo, probably left over from "legacy" versions of the > document prototype. > > All the examples use zcert_new(), and provide public keys up front > to the clients, with > no examples of actually doing a certificate store of just public > keys, and no in-program storage of secret keys. It's almost as if one > is forced to create and distribute secret key files. (there's load > and save options in czmq). > > Let's say I want to store all my public keys in /etc/something/store. > I can distribute that pretty easily to hundreds of machines. > I want to compile a secret key into my servers and clients, for their > respective usage. Clients can fetch the public keys from the disk > store dir. So can the servers. But, the feeling I get from actually > looking over the API's, is that the above is not the intended > usage case. There are no public functions to convert to/from binary > and string key representations. Well, OK, that's entirely fair, > therre is zmq_z85_decode and encode, but I have to wrap that > in a fair amount of code to yield something like > byte secret_key[] = { 0xaf, 0x39, 0x45, 0xc3, .... }; > that I could compile into a program... if that is even the intended > best way to handle keys (shrug). > > Don't get me wrong. I realize this stuff is brand-spanking-shiny-new > and hot-off-the-press, and usage cases are in their infancy. I'd just > like to NOT charge off in a wildly different direction than what you > guys envision, and be left with code I may have to rewrite someday. > > Please, can someone with a higher level view give me some idea of how > I best attack this situation? What's the best way to use this in > production environments, where the server and client are not in the same > executable? > > Pieter, up to writing a "part 3" tutorial outlining separate > servers and clients, using disked public keys, etc? > > One or two variants of suggested "best practice" for clients and > servers will answer all my questions and get me up and running full > speed! > > Many thanks! > > murf > > > -- > > Steve Murphy > ParseTree Corporation > 57 Lane 17 > Cody, WY 82414 > ✉ murf at parsetree dot com > ☎ 307-899-5535 > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
