[cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

Erwann Abalea Erwann.Abalea at docusign.com
Tue Apr 26 08:43:48 UTC 2016


It’s even less than that.

« Current time » is known by everybody, as a CA is unlikely to have non NTP-synchronized servers. The remaining uncertainty on the current time is based on residual offset between UTC and server’s time (hopefully less than 1 second), and the accuracy of the measurement (basically, do you call time() and get a number of seconds, of gettimeofday() and get seconds and microseconds?).
Count slightly less than 10 bits of uncertainty (that’s not entropy) when you increase the accuracy by 10^-3; i.e. you get 10 more bits when measuring milliseconds instead of seconds, and 10 more bits measuring microseconds instead of milliseconds.

Cordialement,
Erwann Abalea

Le 25 avr. 2016 à 09:35, Fotis Loukos <fotisl at it.auth.gr<mailto:fotisl at it.auth.gr>> a écrit :

Hello,
a 256 bit hash of the current unix timestamp does not have 256 bits of entropy, since the possible allowed values are the hashes of all possible values a time_t value can hold (in most systems it's a 64 bit value, thus we have 2^64 different values and an entropy equal to log2(2^64) = 64 bits, and by eliminating past timestamps we get less bits of entropy). I believe that requiring an entropy of at least 64 bits clearly rules out these cases. If we want to be more formal, we can use the 'Shannon entropy' which is very clearly defined and fits our purposes.

I also believe that the current wording leaves it open to various interpretations. For example, someone may claim that after the effective date, any certificates with a serial which is smaller than 64 bits, and thus exhibit less than 64 bits of entropy, should be revoked. I would suggest adding a requirement for certificates having a notBefore after the effective date.

Fotis

On 04/22/2016 07:01 PM, Tim Hollebeek wrote:
This is why I proposed and continue to support an actual definition.  If people don’t like my definition, I’m open to improvements.  I don’t think it should be too hard to come up with one that excludes the four examples Doug mentioned, and I think mine currently does.



-Tim



*From:*public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] *On Behalf Of *Doug Beattie
*Sent:* Friday, April 22, 2016 11:50 AM
*To:* Bruce Morton; Ben Wilson; Dimitris Zacharopoulos; public at cabforum.org<mailto:public at cabforum.org>
*Subject:* Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy



Is there a clear definition of what we mean by Entropy and/or unpredictable bits?    Are any/all of these acceptable:

- Hash of the current date/time

- Hash of the date/time in the certificate

- Using the MS GUID generator

- A lousy random number generator



While we can all look in CT logs for sufficiently long serial numbers, it’s not possible to tell if they were generated with the entropy needed to comply, thus the request.  I think Ryan asked this question earlier this week.



Is this requirement to use sufficient long serial numbers, or to use sufficiently long serial numbers with a minimum level of entropy, randomness or unpredictability?  If it’s the latter, then don’t we need to define what we mean? I don’t see the point in asking for longer serial numbers if there is no spec around the quality of the randomness in the serial number – maybe there is one, but it’s not obvious from the discussion.



Doug





*From:*public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> <mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] *On Behalf Of *Bruce Morton
*Sent:* Friday, April 22, 2016 11:15 AM
*To:* Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com> <mailto:ben.wilson at digicert.com>>; Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto:jimmy at it.auth.gr><mailto:jimmy at it.auth.gr>>; public at cabforum.org<mailto:public at cabforum.org> <mailto:public at cabforum.org>
*Subject:* Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy



I would think that July 1, 2016 would be a good starting point. Would be good to get feedback from any CAs whose product does not support this.



Bruce.



*From:*public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> <mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] *On Behalf Of *Ben Wilson
*Sent:* Friday, April 22, 2016 10:43 AM
*To:* Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto:jimmy at it.auth.gr> <mailto:jimmy at it.auth.gr>>; public at cabforum.org<mailto:public at cabforum.org> <mailto:public at cabforum.org>
*Subject:* Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy



I’d  like suggestions on an effective date.



*From:*public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> <mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] *On Behalf Of *Dimitris Zacharopoulos
*Sent:* Friday, April 22, 2016 2:23 AM
*To:* public at cabforum.org<mailto:public at cabforum.org> <mailto:public at cabforum.org>
*Subject:* Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy



On 21/4/2016 4:07 πμ, Jacob Hoffman-Andrews wrote:

   I think the question of how to define entropy or CSPRNGs is a really good one, but I think the core of this ballot, changing a SHOULD to a SHALL, is too important to hold up on that complex question. How about a version which is strictly no more ambiguous that the current  version:

   "Effective April 1, 2016, CAs SHALL use a Certificate serialNumber greater than zero (0) that exhibits at least 64 bits of entropy."

   Let's Encrypt would be happy to endorse such a ballot.



   _______________________________________________

   Public mailing list

   Public at cabforum.org<mailto:Public at cabforum.org> <mailto:Public at cabforum.org>

   https://cabforum.org/mailman/listinfo/public <http://scanmail.trustwave.com/?c=4062&d=xcia15LZj7OX3h3R_NA-lpiGLbDMK-NzBsHsUQPI3w&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>


In order to make this rule a little clearer, we suggest changing it to:

"Effective XXXX, 2016, CAs SHALL use a Certificate serialNumber greater than zero (0) that exhibits at least 64 bits of entropy for all issued certificates, including CA certificates".

Since this discussion begun in February, I suppose the effective date will be adjusted accordingly to a date after the ballot and not "April 1, 2016".


Dimitris.


---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
---

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.


_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160426/38888a61/attachment-0003.html>


More information about the Public mailing list