What are your thoughts about language suggested on the Mozilla Dev Security 
Policy list under the topic, Undisclosed CA Certificates, “at least 64 bits in 
the certificate serial number SHALL be generated using a CSPRNG”?

 

From: Tim Hollebeek [mailto:[email protected]] 
Sent: Tuesday, May 3, 2016 12:33 PM
To: Ben Wilson <[email protected]>; Erwann Abalea 
<[email protected]>
Cc: Ryan Sleevi <[email protected]>; CABFPub <[email protected]>
Subject: RE: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

 

Ben,

 

The reason I really hate the use of the word entropy is because ANS X9.82 has 
at least 10 different defined terms for various concepts related to entropy and 
entropy measurement, and that’s just in order to start having a reasonable 
discussion about the role of entropy in CSPRNGs.  When people attempt to 
develop audit criteria based on entropy, the results are always amusing, but 
the purpose of the CA/Browser Forum is not to provide me with amusement (a 
shortcoming that hopefully the Governance Reform Working Group can address 
soon).

 

FWIW, their definition of pseudorandom is:

 

“A process (or data produced by a process) is said to be pseudorandom when the 
outcome is deterministic, yet also effectively random as long as the internal 
action of the process is hidden from observation.  For cryptographic purposes, 
“effectively” means ‘within the limits of the intended security

strength.’”

 

The exact details of the definition don’t matter much, since all the bad 
methods will fail to meet any reasonable definition that is reasonably applied. 
 But the use of cryptographic functions and unpredictability by attackers are 
in my opinion the two fundamental features of any non-bad algorithm.

 

-Tim

 

From: Ben Wilson [mailto:[email protected]] 
Sent: Tuesday, April 26, 2016 10:57 AM
To: Erwann Abalea; Tim Hollebeek
Cc: Ryan Sleevi; CABFPub
Subject: RE: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

 

What about,

 

"For certificates having a notBefore date after 1 July 2016, CAs SHALL use a 
Certificate serialNumber greater than zero (0) that exhibits at least 64 bits 
of entropy (i.e. randomness or unpredictability)."

 

?

 

From: Erwann Abalea [mailto:[email protected]] 
Sent: Tuesday, April 26, 2016 2:47 AM
To: Tim Hollebeek <[email protected] <mailto:[email protected]> >
Cc: Ryan Sleevi <[email protected] <mailto:[email protected]> >; Ben Wilson 
<[email protected] <mailto:[email protected]> >; CABFPub 
<[email protected] <mailto:[email protected]> >
Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

 

That’s a good start :) 

 

I find it unfortunate that we need to define in BRs what a CSPRNG is, though.

 

Cordialement,

Erwann Abalea

 

Le 19 avr. 2016 à 16:01, Tim Hollebeek <[email protected] 
<mailto:[email protected]> > a écrit :

 

This is actually a pet peeve of mine that I’d like to fix, though unfortunately 
it is hard to fix.  One of the first security projects I was ever involved in 
involved exploiting bad random number generators to predict who would win a 
poker hand based on just your own hole cards and the flop ( 
<http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5k0rQ3mQ&s=5&u=https%3a%2f%2fwww%2ecigital%2ecom%2fpapers%2fdownload%2fdeveloper%5fgambling%2ephp>
 https://www.cigital.com/papers/download/developer_gambling.php).

 

Various security standards have tried with varying degrees of success to 
describe entropy requirements with generally poor results.  A first stab is:

 

---

A blah blah blah (serial number, challenge, etc) must be generated using at 
least N bits from a cryptographically strong pseudorandom number generator.

 

Definition (Cryptographically strong pseudorandom number generator): An 
algorithm that uses cryptographic functions to generate pseudorandom numbers 
that cannot be predicted by anyone who does not have knowledge of the internal 
data describing the current state of the generator.

---

 

It’s not perfect, because you can use cryptographic functions and still build a 
bad PRNG (hello NSA!), but at least it rules out all the really bad ones like 
rand() that don’t use any cryptographic functions at all, and should allow all 
existing and future secure PRNGs.

 

-Tim

 

From:  <mailto:[email protected]> [email protected] [ 
<mailto:[email protected]> mailto:[email protected]] On 
Behalf Of Ryan Sleevi
Sent: Tuesday, April 19, 2016 9:42 AM
To: Ben Wilson
Cc: CABFPub
Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

 

Ben, is there any thought further on 'unpredictable bits'?

 

While I realize Richard disagreed, I do think it creates a possibility for a CA 
to argue that they're using unpredictable bits from, say, a Microsoft GUID 
generator, but such bits are not unpredictable. My hope would be to provide 
objective and unambiguous criteria, since, as we've seen from this discussion, 
'unpredictable bits' and 'entropy' seem to cause some confusion.

 

On Tue, Apr 19, 2016 at 6:24 AM, Ben Wilson <[email protected] 
<mailto:[email protected]> > wrote:

Then I'll move forward with the  ballot if we have two endorsers.

-----Original Message-----
From: Peter Bowen [mailto:[email protected] <mailto:[email protected]> ]
Sent: Monday, April 18, 2016 9:16 PM
To: Ben Wilson <[email protected] <mailto:[email protected]> >

Cc: CABFPub <[email protected] <mailto:[email protected]> >
Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

I looked at certificates across all CT logs that had notBefore dates in March 
2016.  Only 549 unique certificates had more than 20 bits but less than 61 bits 
in the serial number.  They were spread among many CAs.  >From the looks of it, 
I’m guessing that some CAs using a random number between 0 and N (probably 2^64 
or 2^128) and some percentage of the time the value chosen is less than 2^61.  
I used 2^61 as that is 16 hex digits which is a good approximation of 64-bits.

So, I would say that almost everyone is using at least 64-bit serial numbers 
already.

> On Apr 18, 2016, at 3:45 PM, Ben Wilson <[email protected] 
> <mailto:[email protected]> > wrote:
>
> On the cablint report for the 20 bits of entropy, https://crt.sh/?cablint=38 
> <http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmNsy1rA6lg&s=5&u=https%3a%2f%2fcrt%2esh%2f%3fcablint%3d38>
>  , there  are 20 certificates that were listed.  If this changes to 64 bits, 
> how many more certificates will be on the list?
>
> From: [email protected] <mailto:[email protected]>  
> [mailto:[email protected] <mailto:[email protected]> ] On 
> Behalf Of Ben Wilson
> Sent: Monday, April 18, 2016 10:25 AM
> To: CABFPub <[email protected] <mailto:[email protected]> >
> Subject: [cabfpub] FW: Pre-Ballot 164 - Certificate Serial Number Entropy
>
> Forwarding
>
> From: Kane York [mailto:[email protected] <mailto:[email protected]> ]
> Sent: Monday, April 18, 2016 10:23 AM
> To: Ben Wilson <[email protected] <mailto:[email protected]> >; 
> Erwann Abalea <[email protected] <mailto:[email protected]> 
> >
> Cc: [email protected] <mailto:[email protected]> 
> Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy
>
>
> On Fri, Apr 15, 2016 at 7:52 AM Ben Wilson <[email protected] 
> <mailto:[email protected]> > wrote:
> I didn’t think it was that simple.  For instance, see 
> https://en.wikipedia.org/wiki/Password_strength 
> <http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmNg30uFszQ&s=5&u=https%3a%2f%2fen%2ewikipedia%2eorg%2fwiki%2fPassword%5fstrength>
>  
>
> From: Erwann Abalea [mailto:[email protected] 
> <mailto:[email protected]> ]
> Sent: Friday, April 15, 2016 8:44 AM
> To: Ben Wilson <[email protected] <mailto:[email protected]> >
> Cc: CABFPub <[email protected] <mailto:[email protected]> >
>
> Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy
>
> Bonjour,
>
> 20 bits of entropy is the same as 20 bits unpredictable bits.
>
> Whence, 64 bits of entropy is a higher requirement than 20 bits of entropy.
>
> Cordialement,
> Erwann Abalea
>
> No, it definitely is that simple.
>
> I think the confusion here is the definition of "hex characters".
>
> > Our CA issues certificates with 32 hexadecimal characters for the serial 
> > number.
>
> This is not possible - you cannot have 32 ASCII characters in the serial 
> number.
> The most likely truth given that explanation is that you have 16 fully random 
> bytes. Which would be 16 * 8 = 128 random bits, satisfying the entropy 
> requirements.
>
> 3 fully random bytes would satisfy the 20-bit requirement.
> 6 fully random hexadecimal ASCII characters encoded in the serial number 
> would satisfy the 20-bit requirement.
>
> 8 fully random bytes is required to satisfy the 64-bit requirement.
> 16 bytes with 4 bits of entropy each, which ASCII-encoded hexadecimal would 
> be, would satisfy the entropy requirement and leave you 3.875 bytes left over 
> for other information.
>
>
> Le 15 avr. 2016 à 16:32, Ben Wilson <[email protected] 
> <mailto:[email protected]> > a écrit :
>
> Forwarding
>
> From: Man Ho (Certizen) [mailto:[email protected] 
> <mailto:[email protected]> ]
> Sent: Thursday, April 14, 2016 7:51 PM
> To: Ben Wilson <[email protected] <mailto:[email protected]> >; 
> Ryan Sleevi <[email protected] <mailto:[email protected]> >
> Cc: [email protected] <mailto:[email protected]> 
> Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy
>
> Ben,
>
> We had already changed our system to issue SSL certificates with 20 
> hexadecimal characters of at least 20-bit of entropy since 2014. I'm just 
> wondering why the requirement is changed from "bits of entropy" to 
> "unpredictable bits", which I don't understand the conversion (like "cm" to 
> "inch" :). I don't know whether our software vendor understands it.
>
> Man
>
> On 4/15/2016 4:24 AM, Ben Wilson wrote:
> You’re right, given a randomly generated 20-byte serial number, you have 159 
> unpredictable bits.
>
> From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ]
> Sent: Thursday, April 14, 2016 2:03 PM
> To: Ben Wilson <[email protected] <mailto:[email protected]> >
> Cc: Man Ho (Certizen) <[email protected] <mailto:[email protected]> >; 
> [email protected] <mailto:[email protected]> 
> Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy
>
> Ben:
>
> Are you sure your math is correct? A serial number is 20 bytes, with the high 
> bit needing to be 1 (for the encoding of positive INTEGERS within DER). This 
> leaves 159 bits for entropy. So you certainly can't have more unpredictable 
> bits than that :)
>
> On Thu, Apr 14, 2016 at 12:59 PM, Ben Wilson <[email protected] 
> <mailto:[email protected]> > wrote:
> Man,
> Have you had a chance to do  further research on the capabilities of your 
> system?   Our CA issues certificates with 32 hexadecimal characters for the 
> serial number.  There are 4 bits of entropy for each hexadecimal character.  
> Therefore, our serial numbers have 128 bits of entropy and 16*32= 512 
> unpredictable bits.  An 8-hexadecimal character serial number would have 32 
> bits of entropy and 128 unpredictable bits.  A 20-bit entropy would be equal 
> to 5 hexadecimal characters, or 80 unpredictable bits, so this seems like 
> this is a downgrade to go to 64 unpredictable bits.  Am I right?
> Ben
>
> From: Man Ho (Certizen) [mailto:[email protected] 
> <mailto:[email protected]> ]
> Sent: Wednesday, March 23, 2016 12:27 AM
> To: Ben Wilson <[email protected] <mailto:[email protected]> >; 
> [email protected] <mailto:[email protected]> 
> Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy
>
> Hi all,
>
> Is the meaning of "at least 64 unpredictable bits" setting the same or a 
> higher requirement than "at least 20 bits of entropy" ? I'm not quite sure 
> whether our certificate generation software has this setting in itself.
>
> Cheers
> Man
>
> On 3/1/2016 12:21 AM, Ben Wilson wrote:
> REPLACE
> "CAs SHOULD generate non-sequential Certificate serial numbers that exhibit 
> at least 20 bits of entropy"
> WITH
> "Effective April 1, 2016, CAs SHALL use a Certificate serialNumber greater 
> than zero (0) that contains at least 64 unpredictable bits."
>
>
> _______________________________________________
> Public mailing list
> [email protected] <mailto:[email protected]> 
> https://cabforum.org/mailman/listinfo/public 
> <http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5n17E5nw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>  
>
>
>
> _______________________________________________
> Public mailing list
> [email protected] <mailto:[email protected]> 
> https://cabforum.org/mailman/listinfo/public 
> <http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5n17E5nw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>  
>
> _______________________________________________
> Public mailing list
> [email protected] <mailto:[email protected]> 
> https://cabforum.org/mailman/listinfo/public 
> <http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5n17E5nw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>  
> _______________________________________________
> Public mailing list
> [email protected] <mailto:[email protected]> 
> https://cabforum.org/mailman/listinfo/public 
> <http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5n17E5nw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>  


_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]> 
https://cabforum.org/mailman/listinfo/public 
<http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5n17E5nw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
 

 

 

  _____  


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
[email protected] <mailto:[email protected]> 
https://cabforum.org/mailman/listinfo/public 
<http://scanmail.trustwave.com/?c=4062&d=v4Gf1z01-2acGB72UvmUXuo_-xk5jwJLmI5n17E5nw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
 

 

 

  _____  


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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to