[zeromq-dev] Certificate formats

T. Linden tlinden at cpan.org
Thu Oct 10 15:19:19 CEST 2013

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

- 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.

More information about the zeromq-dev mailing list