When you broadcast a public key for anonymous users to pick up, you cannot encrypt it.
On Tue, Oct 22, 2013 at 2:25 PM, Laurent Alebarde <[email protected]> wrote: > 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 <[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 > > > > > > _______________________________________________ > 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
