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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
