Subject: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 13 Dec 2021 07:42:00 +0000

If there is no further feedback on this topic, I will look for the exact references and change to the new text with the next update.

Hendrik

Von: Brockhaus, Hendrik (T RDA CST SEA-DE)
Gesendet: Montag, 29. November 2021 08:22
An: Salz, Rich <[email-masked]>; Tim Hollebeek <tim.hollebeek=[email-masked]>; Russ Housley <[email-masked]>; Uri Blumenthal <[email-masked]>
Cc: [email-masked]
Betreff: AW: [lamps] CMP draft WGLC: measuring entropy, CA certificates

Rich

Von: Salz, Rich <[email-masked]<mailto:[email-masked]>>
Gesendet: Freitag, 26. November 2021 21:04

  *   Alternatively, I can just state 'guidance' for all of the references. I just would not like to split the list in an 'important guidance' and a 'useful guidance' section :-)

I'm okay with that also.

[Bro] I tend to drop the reference to RFC 4086 then, if no one objects.

  *   In another tread a similar topic was discussed. This reference was proposed there. Even though it is from 2012, I like it and could add it next to the CVE reference as well.
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ffactorable.net%2F__%3B!!GjvTz_vk!EPwUHUVFQX1hiMe8LI2F1Oo70mUnFf1QjzZ-RLiuJ9es_L66DCqFCFQGtbwF%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C7a44016f20bc41e510a008d9b117ee8c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637735538610338323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2F5pMxQasHwedD2ChKq2RgzJvo0TJI4cTW0WfRdD8UmA%3D&reserved=0>>.
https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.usenix.org%2Fconference%2Fusenixsecurity12%2Ftechnical-sessions%2Fpresentation%2Fheninger__%3B!!GjvTz_vk!EPwUHUVFQX1hiMe8LI2F1Oo70mUnFf1QjzZ-RLiuJ9es_L66DCqFCAwW1Iz4%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C7a44016f20bc41e510a008d9b117ee8c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637735538610348279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aCldWoCamju7zuVysrg1%2BBCNMH0U3EAXsRlMItT1NnY%3D&reserved=0>

Sure.  If you think there are too many references, you could just use that one and not the CVE.  Or just both.

[Bro] I think we can keep both.

@Tim, did you have time to think about the paragraphs 2-4? Or should we just go with the first paragraph, like Rich proposed?
@Russ, Uri, what do you think?

Old:
   8.5.  Entropy of random numbers, key pairs, and shared secret
   information

   For requirements regarding proper random number and key generation
   please refer to [RFC4086].

   For the case of centrally generated key pairs, the entropy of the
   shared secret information SHALL NOT be less than the security
   strength of the centrally generated key pair; if the shared secret
   information is re-used for different key pairs, the entropy and the
   security of the underlying cryptographic mechanisms SHOULD exceed the
   security strength of the key pairs.

   For the case of a PKI management operation that delivers a new trust
   anchor (e.g., a root CA certificate) using caPubs, (a) that is not
   concluded in a timely manner or (b) where the shared secret
   information is re-used for several key management operations, the
   entropy of the shared secret information SHALL NOT be less than the
   security strength of the key material being managed by the operation.
   For other cases it is recommended to (a) either use a shared secret
   information of possibly low entropy (e.g., a password) only for a
   single PKI management operation or (b) use a shared secret
   information with an entropy that matches the security strength of the
   key material being managed by the operation.

New:
   8.5.  Entropy of random numbers, key pairs, and shared secret
   information

   Implementations must randomly generate nonces and private keys.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small set of possibilities,
   rather than brute force searching the whole key space. As an example of
   predictable random numbers see CVE-2008-0166 [...], and some consequences
   of low-entropy random numbers are discussed in Mining Your Ps and Qs [...].
   The generation of quality random numbers is difficult. ISO/IEC 20543:2019 [...],
   NIST SP 800-90A Rev.1 [...], BSI AIS 31 V2.0 [...], and others offers valuable
   guidance in this area.

   If the shared secret information is generated by a cryptographically secure
   random-number generator (CSRNG) it is safe to assume, that the entropy
   of the shared secret information is equal to its bit length. If no CSRNG is
   used, the entropy of a shared secret information depends on the details of
   the generation process and cannot be measure securely after it has been
   generated. If user-generated passwords are used as shared secret
   information, their entropy cannot be measured and are typically insufficient
   for protection of delivery of centrally generated keys or trust anchors.

   If the entropy of a shared secret information protecting the delivery of a
   centrally generated key pair is known, it should not be less than the security
   strength of that key pair; if the shared secret information is re-used for
   different key pairs, the security of the underlying cryptographic mechanisms
   should exceed the security strength of the key pairs.

   For the case of a PKI management operation that delivers a new trust anchor
   (e.g., a root CA certificate) using caPubs or genm, (a) that is not concluded in
   a timely manner or (b) where the shared secret information is re-used for
   several key management operations, the entropy of the shared secret
   information, if known, should not be less than the security strength of the
   trust anchor being managed by the operation. For other cases it is
   recommended to (a) either use a shared secret information of possibly low
   security strength (e.g., a password) only for a single PKI management
   operation or (b) use a shared secret information with an entropy that matches
   the security strength of the key material being managed by the operation.

Hendrik