The client random value does not need the same quality of randomness that would be desired for a private key generation process – especially a long term key. I would need to sit down and think about it, but it is quite possible that a counter would work for the client random value. The main thing you want with this is non-repeating so that the final secret is always uniquely generated. There have been cases where time has been part of this random value and I don’t believe that it makes the final key any less secure.
Jim From: Ace [mailto:[email protected]] On Behalf Of Samuel Erdtman Sent: Monday, June 06, 2016 9:58 PM To: Julien Vermillard <[email protected]> Cc: [email protected] Subject: Re: [Ace] Constrained Environment PKI enrollment Okay so there needs to be some sort of random number generation for the TLS-PSK handshake, I was not aware of that. (is the requirements on it as rigor as for the key generation) The other reason I could think of that is kind of mentioned previously, it is the "quality" of the generated key, in some deployments, FIPS certified key generation is required and that could be easier to guarantee server-side. But it might be that there are no absolute situations where server-side key-generation but rather a design option. //Samuel On Mon, Jun 6, 2016 at 5:05 PM, Julien Vermillard <[email protected] <mailto:[email protected]> > wrote: Yes, but since you need some random numbers for doing a TLS-PSK handshake (ClientHello random) why a TLS-PSK client should no be able to generate ECDSA keys? -- Julien Vermillard On Mon, Jun 6, 2016 at 4:30 PM, Samuel Erdtman <[email protected] <mailto:[email protected]> > wrote: Hi Julien, The first one that comes to mind would be where Pre-Shared-keys are used i.e. symmetric keys. These keys could be factory keys used only to setup the PKI-keys. If you look at EST the server generated keys is also recommended to be wrapped in an extra layer of encryption in addition to the transport layer security (DTLS/TLS). So if the transport layer security is not absolute no keys should be leaked. //Samuel On Mon, Jun 6, 2016 at 3:18 PM, Julien Vermillard <[email protected] <mailto:[email protected]> > wrote: Hi Samuel, I wonder in which scenario a RNG is safe enough for running a DTLS stack but not good enough for generating a ECDSA key couple? -- Julien Vermillard On Fri, Jun 3, 2016 at 5:08 PM, Samuel Erdtman <[email protected] <mailto:[email protected]> > wrote: The company I previously worked for where looking into adopting EST for this purpose, the benefit of EST compared to cmp or scep was that it defined the process for server side generated keys, which could be beneficial if key generation would be to cumbersome for the device or if you don't trust the device to generate a "good" key. Maybe Shahid could give sold more updates since he was helping us with this project On Thursday, 2 June 2016, Julien Vermillard <[email protected] <mailto:[email protected]> > wrote: Hi, In industrial or enterprise M2M/IoT application we often use PSK for authentication, but more and more user want to enroll the device on their public key infrastructure like they does with some routers using SCEP/CMP. I wonder if it was explored to enroll devices, and renew certificates on PKI only using CoAP and not HTTP? -- Julien Vermillard
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
