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