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 > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
