[zeromq-dev] Certificate formats

[Tony Arcieri]

On Thu, Oct 10, 2013 at 6:19 AM, T. Linden <tlinden at cpan.org> wrote:

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

Yes, each node will need to generate its own keypair, and have a cert
contained its public key signed by the org's CA.

What each node *doesn't* need is to have every single public key of every
other node on the grid.


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

I think you're misunderstanding. It's not a database. It's not listening on
a network port. It doesn't have to be available.

 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
>

I think I'm halfway there already. Worked on this last night ;)

https://github.com/cryptosphere/ordo

(actual CFG forthcoming)

That's a lot of stuff and it's not easy to maintain. And it looks like
> X509 again


What you wind up with will, no doubt, be conceptually similar to X.509.
That's not to say that there's zero room for improvement from X.509. Far
from it.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131010/4d15acff/attachment.htm>