This assumes the use of a software RNG that can be open sourced. Many CAs may be using a hardware source of randomness, such as a HSM, which runs proprietary code they do not hold the license to.
On 04/30/2016 06:45 AM, Eric Mill wrote: > On Fri, Apr 29, 2016 at 8:12 PM, Peter Bowen <[email protected]> wrote: > >> On Fri, Apr 29, 2016 at 5:03 PM, Matt Palmer <[email protected]> wrote: >>> On Fri, Apr 29, 2016 at 12:42:28AM -0700, Nick Lamb wrote: >>>> There is an absolutely objective test, but it is negative. If anyone can >>>> predict N-bits of your next serial number then those N-bits were by >>>> definition predictable. To give a concrete example if you issued with >> 16 >>>> digit serial numbers, but the first 8 are YYYYMMDD from the actual date, >>>> any bad guy can predict those numbers in the next certificate, thus they >>>> don't constitute entropy / unpredictable bits, so your serial numbers >> have >>>> no more than 8 digits of entropy in this scenario. >>> >>> Even more fun: what if the serial number is MD5(YYYYMMDDHHmmss)? In that >>> case, comparing two serial numbers makes them all *look* awesomely >> random, >>> until someone figures out "the secret", at which point pretty much all >> the >>> bits are predictable, even though there's no "obvious" pattern from >>> examining the serials themselves. >> >> What if the serial number is HMAC-MD5(SecretStaticKey, >> YYYYMMDDHHmmss)? Or AES encryption of the timestamp? >> >> This is why there are human auditors. They can ask the CA how they >> are generating the serial numbers. That is the only way that this can >> every be verified. >> > > Or a CA could release this part of their infrastructure as open source (or > at least publicly disclosed), and have the auditor attest that the code > used in production is the code in public version control. That would make > it so the community, not just the auditor, could evaluate of the strength > of the methods the CA uses to manage entropy while being assured that > they're evaluating the actual production code. > > -- Eric > > >> >> Thanks, >> Peter >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
