Hi Chris, [EMAIL PROTECTED] wrote:
1. The the new design must support large volume installations, and the time taken to perform operations must not increase exponentially with the number of certificates in the PKI.
This was the reason for the new design.
2. A mechanism must be provided to allow a full update to be completed to allow, for instance, a node to be rebuilt in the event of systems failure (e.g. a CA or RA is re-built form a previous weekly backup).
Something like the backup mechanism of the old design.
3. It might be sensible to consider providing for the compression of exchange files (especially useful for slow network links, high volume systems or restricted media size).
This can be done today too via the -z option of tar. This option is not a default option because of some vendors like Sun which are not able to extend their tar.
4. The new exchange solution must still support the configuration where the RA and CA "share" a single database.
Means no exchange :)
5. It would be useful if the import/export routines were accessible from the new API. The important feature here is the ability to fully "automate" the task. The latest design documentation suggests that there may be 2 separate actions a maintenance action and an export/import action. If this is the case then it should be possible to automate both actions.
All commands are only usable via the API. If we add the dataexchange stuff to the shell interface then you can use it with cronjobs :)
6. The "Maintenance Command" seems to perform a scan for missing entries. We are worried that this could be a performance overhead. If the PKI is a 100,000 certificate system, you are asking this maintenance command to go through each of the records in the database and check to see if it exists in the data exchange log. At the moment this takes a _VERY_ long time and we are worried that this performance problem has not been addressed in this design.
This is not so slow because we can perform it in native SQL. The old code performs the scan by itself - one query per certificate. The new solution performs one query for every type and status. Example:
select * from ca_certificate where ca_cert_key not in
(select object_key from dataexchange where
object_type="CA_CERTIFICATE" and object_status="VALID")
We only have to perform an expensive scan if we have a new server in the
dataexchange configuration.
Could the OpenCA functions not be modified to populate the data exchange log as they update the database with new records, i.e. populate the log when it knows it has new elements ?
We can try to integrate this into the DBI module (like a trigger but in software). If update or insert are called then we check the dataexchange table for appropriate entries. It sounds reasonable and we can avoid the complicated maintenance command. The "hook" already exists for the audit trail.
7. This may be my understanding of the flow description, but we often have to perform a data exchange twice (becasue the media has failed or the RA was not available etc). Can you confirm that the design of the "EXPORT" and "PENDING" states does not stop the CA/RA from exporting the correct data even if an import is not received. I hope you understand what I am trying to say here.
The behaviour is like on the old system. If you export something and the media is lost then the exporting node recognizes the media loss after the first important from the target node after the media loss. I hope my English is clear enough here.
Perhaps more clear - a media loss is recognized after the first answer from the target.
8. Is it worthwhile giving some consideration as to how the new import/export implementation fits in with the future need of "real time" certificate generation ?
... if you can explain what do the special requirements be then yes :) 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 _______________________________________________________________
smime.p7s
Description: S/MIME Cryptographic Signature
