[EMAIL PROTECTED] - Mon Mar 15 18:59:21 2004]: > Stephen Henson via RT wrote: > > > I'm not sure how portable that patch is as it stands. > > What would be the portability problem? The code is already calling > time() in order to calculate the expiration dates. >
Oops, sorry. I thought that all time() calls went through other sections of the library. I see now that the openssl app has explicit calls to time() so it is portable. > >As a portable alternative we could use a large random number for the > >serial number, for example a 159 bit one has negligible chance of > >duplicates. > > > > > That seems to be overkill--64 bits would be more than sufficient. > OK. > >I'd be interested to know how people are managing to create duplicate > >serial numbers: that is what commands and or scripts are being used > to > >do this. > > > > > I've asked someone with more direct experience with this to comment on > the ticket. As I understand it, there are at least two situations: > One, the CA somehow loses its serial number file--it rebuilds the box, > regenerates the CA cert from scratch, or whatever. Two, the user > generates a self-signed cert with "openssl req -x509" and no serial > number options, resulting in a cert with (nonconforming) serial number > 0. > Then there are possibly other situations as well. One would be the perl front end CA.pl which initializes the serial number file for the 'ca' utility. That can be fixed easily enough. Another would be if non-standard scripts initialize the serial number file either for 'ca' or the 'x509' utility. With regard to 0 being a non conforming serial number. RFC3280 in 4.1.2.2 says serialNumber must be positive (which would exclude 0) and in the next sentence non-negative (which wouldn't). Steve. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
