173872 - certutil's default serial numbers should increase monotonically

Status: RESOLVED FIXED

(NSS :: Tools, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

There is an O'Reilly book named "Creating applications with mozilla".
The text of that book also may be found online at http://books.mozdev.org/

Chapter 12 of that book, http://books.mozdev.org/chapters/ch12.html#77080
contains instructions on how to operate a CA using certutil.  

The instructions do not use certutil's -m option to set the serial number 
in the generated cert explicitly.  Instead, they rely on certutil's 
default source of serial numbers to generate serial numbers.  

Certutil's default source of serial numbers is the low-order 32 bits in
the value of PR_Now, which IIRC is the number of microseconds elapsed since
midnight, Jan 1, 1970, UTC.    The low order 32 bits of any microsecond 
value wrap around every 71.58 minutes.  On systems where PR_Now has no more 
than than 1000 unique values per second, the probability of duplicate serial 
numbers is too high, IMO.

So, I propose to change certutil's default source of serial numbers to
(PRUInt32)(PR_Now >> 19), which has a resolution of about 1/2 second, and
wraps around about once every 71 years.  Hopefully after that long, no-one 
will still be using certutil as a CA.

Here's the proposed patch to certutil.c

        /*  Make a default serial number from the current time.  */
        PRTime now = PR_Now();
+       LL_USHR(now, now, 19);
        serialNumber = LL_L2UI(serialNumber, now);

Barring objections, I will check this change in soon.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Marking P1 for 3.7 because of the potential NSS support burden.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I have one concern about the proposed fix.  
On some fast systems, if a script is running certutil repeatedly, issuing
certs from the same CA (same issuer name), it may be possible for certutil
to issue two certs within the same approx 1/2 second time interval, 
resulting in two certs with the same serial number.  

Just by running our cert.sh test script on my old 733 Mhz PC, I have found 
certs being issued with serial numbers only 2 apart.  

Unfortunately I think the only good solution is to stop trying to create
certs with 32-bit serial numbers, and go to 64 bit serial numbers.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Attachment: numerous changes to serial number handling

This patch makes several changes to certutil.
1. All veriables that hold serial numbers are changed from int to unsigned.
2. If no serial number option is given on the command line, the serial number
is taken from PR_Now >> 19

This patch also makes some other changes.
3. Fixes bug 1746549 with a one line change, adding a \n
4. removes some unused variables
5. removes some very old code that was #ifndef NSPR20

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I have checked in this patch.  
Although all.sh passes on my machine, it might fail on a very fast machine,
for the reasons explained above.  I will watch tinderbox.  

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

QA passed list night on all platforms.  Marking fixed.
If we get reports of certutil issuing certs with duplicate serial numbers,
the shift factor will have to be reduced.