On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
> Mike Kushner via dev-security-policy <dev-security-policy@lists.mozilla.org>
> writes:
>
> >EJBCA was possible the first (certainly one of the first) CA products to use
> >random serial numbers.
>
> Random serial numbers have been in use for a long, long time, principally to
> hide the number of certs a CA was (or wasn't) issuing. Here's the first one
> that came up in my collection, from twenty-five years ago:
Thanks Peter, you have an impressive collection (no irony, it is really cool!).
We still get asked by customers to implement sequential serial numbers from
time to time, but it's getting more and more rare.
>
> RFC 3280 (2002) explicitly added handling for random data as serial numbers:
Ha, we were way before RFC3280 :-). Just being geeky, here is the code from
EJBCA 1.0 (2001-12-05). CSPRNG, although it was seeded differently at that time
(setSeed complements not replaces self-seeding in SecureRandom).
random = SecureRandom.getInstance("SHA1PRNG");
random.setSeed((long)(new Date().getTime()));
byte[] serno = new byte[8];
random.nextBytes(serno);
(https://sourceforge.net/projects/ejbca/files/ejbca1/ejbca-1_0/)
> Given the uniqueness requirements above, serial numbers can be
> expected to contain long integers. Certificate users MUST be able to
> handle serialNumber values up to 20 octets.
I know it's rare, but we've had clients with devices that can not handle more
than 32 bits. Not WebPKI of course... Your X509 Style Guide is still a classic
read btw.
> (20 bytes being a SHA-1 hash, which was the fashion at the time).
You make a good point there. The mere size of the serial number doesn't say
much about the entropy. The auditor has to dig into the details.
Cheers,
Tomas
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
