Hi Michael, >> I also wondered about the NUMBER() data type (and used it in another >> application for serial number storage as well). >> I think NUMBER(31) is perfectly OK for storing cert serials: >> >> log_16 10^31 = 25.74 >> >> So we can store 25 hexadecimal digit serial numbers in this data type, >> more than enough for the RFC requirements, if I am not mistaken. > > What do 20 octets be? (8^20) or (8 bit *20)? If 8^20 is correct then > Oracle's and IBM's datatypes are big enough and we can commit the patch > to openca_0_9_2.
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. How about the following solution: - use a VARCHAR() of at least 20 digit length for storing the serial number - store the cert serial as hexadecimal number in this VARCHAR - introduce a new NOTBEFORE column for the certificate table (we need this for rollover handling anyway) - change sorting semantics for display: do not sort on serial numbers anymore, but rather on the NOTBEFORE date 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 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. Just our thoughts (after brief discussion with the folks here). Martin ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ OpenCA-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-devel
