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
