[zeromq-dev] Certificate formats

Tom Cocagne tom.cocagne at gmail.com
Fri Oct 4 07:13:44 CEST 2013

One of the widely accepted failures of the existing TLS security model is
that the certificate handling approach is overly complex and easy to get
wrong. A while back I spent several days with the OpenSSL book and a bottle
of aspirin in an attempt to accomplish a single goal: "Ensure that these
two machines, and *only* these two machines, can connect via SSL". I got it
working, of course, but how confident am I that the dozens of options I had
to specify along the way have lead to a secure system with no holes? Not
very. Some things in the certificate chain are required, some aren't. Some
things the library checks for you, some are left up to you. And that's just
when you're doing the easy stuff. How about correctly handling multi-homed
machines that could legitimately connect from multiple source IP addresses
that resolve to differing DNS hostnames? It'd be a trivial issue if I could
just put a UUID in the cert... but there doesn't appear to be any good
place to put it. Can I just stuff it in some other field that wasn't
designed to carry a UUID? Will that inadvertently break something now or in
some future version of OpenSSL? I have no idea. PKI is pretty
straight-forward at a conceptual level but TLS certificate handling has
made a mess of things.

When we think of certificates for secure network communication, I think we
tend to throw in a bunch of assumptions that aren't always true. For
example, at the most fundamental level a certificate "binds a public key
with an identity" (to quote wikipedia). The implicit assumption here is
that the certificate would be worthless without the identity being
associated with the public key. That's certainly true if you're going for
the full PKI model but isn't true for all real-world use cases. Lets say
I'm setting up a handful of servers and want them to be able to communicate
freely and securely with each other. There really isn't any need to assign
each an identity and have the others check it. The simple fact that their
public key has been signed by the CA's private key is sufficient. I also
don't need CRLs. If any machine is compromised, I can just create a new CA
and re-key each system. Of course, this approach doesn't scale at all but
it does illustrate that at least some of the certificate "essentials" are
not always useful or desirable.

You mentioned that "...there are many things certificates need to do...".
This might more accurately be phrased as "there are many types of
information certificates must support". Clearly, the certificates
themselves don't actually do anything. Their singular and critical
responsibility is conveying the necessary information to allow the consumer
to judge whether or not an operation should be permitted. What information
is required though is completely application dependent. It could be almost
nothing at all, as in the simple example above, or it could be a chain of
certificates with a UUID, all allowable subnets the host may to operate on,
and a flag to indicate that this certificate may be used for digitally
signing orders for thin-mint Girl Scout cookies (but not the peanut butter
ones... I'm not a big fan of those ;-)

The obvious problem with not formally standardizing the metadata included
in the certificates is interoperability. However, if this approach were to
take off, I suspect that interoperability would evolve over time in the
form of a few de-facto standards. I wouldn't be surprised to see something
like the following in a few years:

==== Begin ZMQ Cert ====
uuid: 9af3d710-e762-4cf4-a9cb-e5a5899bf3c8
public_key: 81A...BF
    name: cool_zmq_app_server
    webserver_port: 1234
    dns_name: org.cocagne.home_network.cool_zmq_app_server
    http_port: 1234
    client_authentication_required: True
==== End ZMQ Cert ====


On Thu, Oct 3, 2013 at 3:13 PM, Tony Arcieri <bascule at gmail.com> wrote:

> On Wed, Oct 2, 2013 at 12:11 AM, Pieter Hintjens <ph at imatix.com> wrote:
>> So this may be a very stupid question, but what does a certificate
>> have to hold that is so complex?
> Well, first, I'm not sure what I'm describing that's "so complex" ;)
> Simplicity is my aim! But there are many things certificates need to do in
> the scope of organizational usage, especially in large systems administered
> by many people.
>> We have one or two keys, some meta
>> data... why would you'd be thinking of anything more complex than
>> plain text?
> Certificates need to contain the following:
> - Identities (i.e. DNs)
> - Relationships between identities (i.e. issuers, chains of trust)
> - Keys
> In an infrastructural scenario, we may want certificates to all belong to
> an organization, but limit authority at various levels of granularity, i.e.:
> 1) Do we all belong to the same organization?
> 2) Are we in the same office/country?
> 3) Are we in the same OU/division/datacenter?
>> For a grid, yes, a certificate server seems the right model. I've not
>> thought about CRLs as we don't have the use case for revocation yet.
> If you do have grids that trust a CA for authentication (perhaps checking
> OUs or whatever) you will want a way to revoke the keys/certificates of
> nodes that are compromised.
> --
> Tony Arcieri
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131004/27628470/attachment.htm>

More information about the zeromq-dev mailing list