[zeromq-dev] Proposal for ZeroMQ certificate storage

[Pieter Hintjens]

Did you have any comments on http://hintjens.com/blog:62?

There's some overlap with your suggestions.

On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde <l.alebarde at free.fr> wrote:
> 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:
>
> The certificates SHALL be able to be accessed in an efficient way using a
> hash table or even an array.
> For huge client base, a choice of databases, relational or nosql, SHOULD be
> possible
> 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"
> The client key pair SHALL be able to be generated in the client or in the
> server, at designer's choice.
> 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.
> The certificate on the client side shall contain the server's certificate
> storage key.
>
> Rationals :
>
> Efficiency on the first step of the hand-check is a key against DDOS
> attacks.
> Database enables a good memory management and offers replications /
> synchronisation.
> 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.
> The most secure is probably in the client ?
> Having dedicated server keys per client is not so expensive, so let it be
> possible for every one who wish it.
> 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:
>
> Both server and client generate a key pair.
> The client transmit its public certificate to the server (only its public
> key).
> The server creates a certificate which contains its own key pair dedicated
> to this client, and aggregates the client public certificate received.
> 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.
> 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
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
-
Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com