If the CA/Browser Forum were to articulate such a requirement, i.e., "at least 64 bits in the serial SHALL be generated using a CSPRNG", then what is a reasonable amount of lead time to give CAs to incorporate this requirement into their systems/processes?
-----Original Message----- From: dev-security-policy [mailto:[email protected]] On Behalf Of Roland Shoemaker Sent: Saturday, April 30, 2016 11:03 PM To: Eric Mill <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: Undisclosed CA certificates Ah yes, that is true. It is still the case though that a CA could be calling out to some third party library or such they are not at liberty to disclose. Another thing to point out is that defining the structure that strictly (i.e. MUST be a HMAC of something) would prevent a number of CAs from storing various other structure within the serial (including Let's Encrypt, in the code you linked we append our '8-bit instance id prefix' to define from which instance a certificate was issued). It seems the best solution to this problem is to simply remove the use of entropy and require that N number of bits in the serial were generated using a CSPRNG. The term is relatively well defined such that an auditor (or other party) should be able to determine if a CA is complying given the process by which they generate the required bits. On 04/30/2016 03:12 PM, Eric Mill wrote: > I understand that, but I would assume that the choice of what to ask > the HSM to do would be in the CA's own software. This was the question > I was responding to: > > >> What if the serial number is HMAC-MD5(SecretStaticKey, YYYYMMDDHHmmss)? > Or AES encryption of the timestamp? > > That seems like CA-land code. In Let's Encrypt's boulder, it looks > like the answer is here: > > https://github.com/letsencrypt/boulder/blob/b7cf618f5d228ba2699e09cc4a > 65888d61654b19/ca/certificate-authority.go#L499-L512 > > -- Eric > > On Sat, Apr 30, 2016 at 5:34 PM, Roland Shoemaker > <[email protected]> > wrote: > >> 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 >> > > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
