Hi,
I migrated the first batch command to CVS HEAD. The name of command is
batch_cmd_create_pin.
The batch commands are now fully integrated into the normal API and they
use the API including the access control mechanisms. Someone could say
the batch system is the only user interface which is i
Hi,
>> - 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.
VARCHAR instead of CHAR also allows for shorter and easier to
read/process serials, e. g. '105' instead of
'
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 adde
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 t
Oliver Welter wrote:
I dont know why the "stop" scritp does not take down the process, but I
recommend a simple change: a grep inside the start-script shpuld check
if there is a process running and at least warn the user
Good idea but please only warn the user. Some users (including me) run
Hi Oli,
Oliver Welter wrote:
I am currently working on the batch processor for revoking and renewal.
I have situations were a user re-request a new certificate with changed
data during the lifetime. So I must revoke the "old" certificate when I
issue an new one. From the "usability" point of view
Martin Bartosch wrote:
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 t
Hi,
> I was a little bit sceptical about the DBI fixes and therefore it take a
> little bit more time than usual to check the patch. I found some problems:
>
> Oracle: it support number(49) but only with a precision of 38 numbers
> IBM:it support numeric(49) but only with a precision of 31 num
Alexei Chetroi wrote:
1st. CA certificate, even if created with -set_serial 01 is stored in
database under key which look like hexadecimal number. So cmd listCerts
list ca certificates referenced by serial number different from the real
one.
This is a hash from the CA certificate.
2nd. getOwner in
