[zeromq-dev] Proposal for ZeroMQ certificate storage

[Laurent Alebarde]

Hi everybody,

In addition to the format, a discussion about the storage of the 
certificates may be usefull.

I propose the following (I am very verbose so that I can understand 
myself in one week ;-) ):

Requirements:

 1. The certificates SHALL be able to be accessed in an efficient way
    using a hash table or even an array.
 2. For huge client base, a choice of databases, relational or nosql,
    SHOULD be possible
 3. The key that permit to retrieve the certificate SHALL be able to be
    transmitted in plain text, without compromising security. Thus, the
    public key SHALL not be considered as a valid key, even if many
    people consider the public key can be public. Let's call it the
    "server's certificate storage key"
 4. The client key pair SHALL be able to be generated in the client or
    in the server, at designer's choice.
 5. The certificate on the server side SHALL contain at least the client
    public key, but SHALL be able also to contain a server key pair
    dedicated to this client.
 6. The certificate on the client side shall contain the server's
    certificate storage key.

Rationals :

 1. Efficiency on the first step of the hand-check is a key against DDOS
    attacks.
 2. Database enables a good memory management and offers replications /
    synchronisation.
 3. The server's certificate storage key cab be sent in plain text by
    the client in the HELLO message. When the server generates the
    certificate, its server's certificate storage key can be a hash of a
    function of the registration data of the client, or simply the
    client number, or whatever appropriate to the designer. Then, the
    server's certificate storage key is completely decorrelated from the
    cryptographic keys. The server's certificate storage key is
    transmitted to the client along with the certificate which contains
    the server public key.
 4. The most secure is probably in the client ?
 5. Having dedicated server keys per client is not so expensive, so let
    it be possible for every one who wish it.
 6. to enable the server to retrieve the appropriate certificate from
    its storage

Here is a possible scenario in the frame of a client registration under 
TLS or equivalent:

 1. Both server and client generate a key pair.
 2. The client transmit its public certificate to the server (only its
    public key).
 3. The server creates a certificate which contains its own key pair
    dedicated to this client, and aggregates the client public
    certificate received.
 4. The server generates an arbitrary key for this certificate, say a
    hash of the two public keys, the clients organisation name and
    client number, and checks it is unique - if not, add one until it
    is. This is the server's certificate storage key.
 5. The server transmit this key and its own public certificate to the
    client which aggregates the information in a final certificate that
    contains the client key pair, the server public key, and the
    certificate key.

When the client sends HELLO to the server, it sends a modified HELLO 
that contain the certificate key. With this key, the server retrieve the 
appropriate certificate from an array, a map, or a database, and proceed 
with the hand-check.

It is important to recall of course that I am not a security expert, nor 
a cryptography expert. It is just the expression of a system designer 
with performance, security and simplicity in mind.

I may put that in a RFC if it is desirable.

Cheers,

Laurent




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131022/70304253/attachment.htm>