Hi Pieter,
I have only one small comment inside "Use Cases": Why storing the public
key in plain text when it does not hurt to crypt it ? It is a question
of philosophy. One of my design principle for everything is to not
degrade performance, even when it looks not hurting, as far as it is cheap.
Otherwise, what is below do not overlap and represents mainly some
possible answers to "/What's missing here is some proposal for standard
filenames and certificate locations on disk. This should be part of a
standard specification, I think./"
Cheers,
Laurent
Le 22/10/2013 12:55, Pieter Hintjens a écrit :
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.aleba...@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@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
