I will, once I get my head out of this book I'm writing (http://hintjens.com/blog:_cande), come up with a *minimal* proposal that does more or less what Tom needs for his curve keygen. I've no opinion on CAs nor chains of trust nor anything else except that it's outside the problem zone today. That is, creating, storing, and exchanging CURVE certificates, no more or less. By discussing stuff that we don't yet need to solve, we're not talking about immediate problems. Perhaps they're too banal, or obvious, but I'd rather not make assumptions.
Tom, you are focussing on secret keys here, but we also need to exchange public keys safely, right? Can you comment on public keys + metadata? Encrypted or not? Safe to paste into email? -Pieter On Thu, Oct 10, 2013 at 3:19 PM, T. Linden <tlin...@cpan.org> wrote: > On Wed, Oct 09, 2013 at 09:21:29AM -0700, Tony Arcieri wrote: >> Certificate authorities don't have to be, let's say, DigiNotar, nor do >> they even have to be organizations you pay money to. A CA is something you >> can set up internally within an organization to sign certificates that are >> used by your internal services (this is what we do at my day job at >> Square) > > Yes, that's right. But that's the case for SSl as well. And once you > need those certificates for public communication, you'll end up with > public CAs. That's what I wanted to say. > >> * We want each node in the grid to have a unique certificate/private key >> * We want nodes in the grid to be able to authenticate each other and >> determine they actually belong to our org >> * We don't want to have to pin a bunch of certificates on every single >> node in the grid every time we add a new node > > The third point contradicts the first two, I'd say. If you want to have > unique keypairs on each node, you'll need to create and/or distribute > them to every new node. > >> * We don't want to have to consult a central database of trusted >> certificates every time two nodes try to connect to each other >> >> An issuing authority (i.e. Your Organization) trusted by all nodes in the >> grid solves this problem nicely in a decentralized manner that doesn't >> involve consulting some trusted central database every time two nodes want >> to talk. > > Actually an issuing authority IS a central instance, IMHO. > > There's another thing: you'd need to define the term "issuing". If we > look at SSL, issuing there actually means signing. Every certificate > user - usually - generates a certificate signing request and a private > key along with that. The authority then generates the public key from > the CSR and signs that with its private key. > > If you want to replicate such a mechanism, then X.509 is the way to go. > Or I understood the wrong thing about "issuing", than clarification > would be good. > > From what I see, you'd need at least the following in such a > certificate: > > - an OID (or common name, what ever) of the private key > - the keypair algorithm (Curve25519, maybe others in the future) > - is the private key encrypted or not (a boolean) > - if it is encrypted, the encryption scheme used > - the actual private key > - the public key (optional) > - a version number of the certificate file format > - a version number of the certificate itself (aka serial #) > - a signature > - again the scheme used for the signature > - the OID of the signing private key > - a timestamp of the creation time > - optional: expire time > > That's a lot of stuff and it's not easy to maintain. And it looks like > X509 again :) There's btw a standards proposal for EC private keys: > RFC5915. It refers for public keys to X509. > > Such a scheme might be useful in some setups but too much for others. In > my own case I don't need signatures, issuers, epire times and all that > stuff. I need just the keys and a name for each one. > > > > > - Tom > > > > -- > PGP Key: https://www.daemon.de/txt/tom-pgp-pubkey.txt > S/Mime Cert: https://www.daemon.de/txt/tom-smime-cert.pem > Bitmessage: BM-2DAcYUx3xByfwbx2bYYxeXgq3zDscez8wC > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
