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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
