On Thu, 2014-05-15 at 22:49 +0200, Josef Wolf wrote: > On Thu, May 15, 2014 at 01:49:14PM +0200, Nikos Mavrogiannopoulos wrote: > > On Thu, May 15, 2014 at 12:08 PM, Josef Wolf <[email protected]> wrote: > > > Hello, > > > I am currently trying to use UUIDs (as Bignum) for the serial number of > > > certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a > > > hard > > > time to specify more than 31 bits in the template file. > > > With a prefix of 0x (indicating hex number), I get serial number 0. Ough! > > > Given as a decimal number, the number is truncated to 0x7fffffff. > > > Is this a limitation in certtool or am I missing something? > > > > It was a limitation. Support for up to 63-bit serial numbers was added in > > 3.3.0. > > Well, I don't think the limitation is really removed. The RFC specifies this > field to 20 octets. That would be 160 bits, right? To store a UUID, 128 bits > would be needed.
That is the maximum number allowed, not a recommended value or so. > For me, it's not a big deal. I don't expect to ever need more that 10 > certificates per CA. 31 random bits would be more than enough for me. In the > case of a collision, re-generating the certificate would be no big deal. > But for real-world applications, defaulting to (internal generated) UUID > instead of time-based serials would be a _big_ win. IMHO. The purpose of certtool is to provide an easy way to generate certificates for simple purposes and a 64-bit serial number seemed sufficient at the moment. I'd certainly consider though any enhancement patch that allows for arbitrary serial numbers. regards, Nikos _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
