Hi Martin,

Martin Bartosch wrote:

you are right, I remembered the RFC incorrectly (and did not check
it before writing my answer). It's 20 octets, not 20 hex digits,
so this means

2**(20*8) == 2**(160) or roughly 1.46 * 10^48, so we'd need a
NUMBER(49) to handle the full serial number range.

I added yesterday such a calculation to the docs of DBI.pm.

How about the following solution:

- use a VARCHAR() of at least 20 digit length for storing the
  serial number

How about 49 or 48 characters? We don't need varchar if we only support 20 numbers.

- store the cert serial as hexadecimal number in this VARCHAR

Why should we use a hexadecimal representation? It costs a lot of work to always use decimal numbers at all places in OpenCA.

- introduce a new NOTBEFORE column for the certificate table
  (we need this for rollover handling anyway)

DONE.

- change sorting semantics for display: do not sort on serial
  numbers anymore, but rather on the NOTBEFORE date

DONE.

This approach has the following advantages:
- fully RFC compliant
- alternative serial number schemes (e. g. concealed serial numbers)
  could now become a simple configuration option

I think this is a good idea. I introduced now a new type NUMERIC in OpenCA::DBI but I use it very carefully to don't damage the ordering of normal serials (like from requests).

I think we won't even have to perform any mathematical operation on
the serial number if the serial number generator is implemented
properly (e. g. using a DB sequence or count(*) for determining
incrementing serial numbers or SHA1(salt, sequence) for concealed
numbers.

I think too that this is correct. Only the ordering is a little bit difficult because not all objects maintain a notbefore field. Therefore we have now two datatype NUMERIC and BIGINT.

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
[EMAIL PROTECTED]   D-10099 Berlin
_______________________________________________________________

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



Reply via email to