Hi all,

I start thinking about reworking the export/import-mechanism
since I know that Julio evaluate a new way to speed up our
display-performance.

There are two open issues. We must create smaller exports
and support more flexible hierarchies. The following is the
minimum:

CA DB <---> RA/LDAP DB <---> Public DB

or for all the security experts

CA: Offline-DB
RA/LDAP: Online-DB in private zone
Public: Online-DB in DMZ or directly connected to the internet

The result should be an interface called node. A node (in a tree)
includes the follwing functions:

- database management
- export/import with other levels

The web-interface node must be installed on every server where a
database of OpenCA exists.

Databasemanagement
------------------
- initialization
- backup
- recovery

Export/Import
-------------
- dataexchange with higher level (download/upload)
- dataexchange with lower level (receive/enroll)
- never accept received objects which already exists in the database
- the new functions should be
- receiveCRR
- receiveCSR
- receiveAll
- enrollCRR
- enrollCSR
- enrollCert
- enrollCRL
- enrollConfig
- enrollAll
- uploadCRR
- uploadCSR
- uploadAll
- downloadCRR
- downloadCSR
- downloadCert
- downloadCRL
- downloadConfig
- downloadAll

- functions in export-import.lib are the same like before only
one option must be added - ALLOW_STATE_INJECTION. This parameter
is only used by CSRs and CRRs if we download them from a higher
level. Every other state-injection is not allowed.
- enrollCRR and enrollCSR are necessary to enroll deleted requests

Extra configuration parameters
------------------------------

ENROLL_CRR_STATES
RECEIVE_CRR_STATES
DOWNLOAD_CRR_STATES
UPLOAD_CRR_STATES
ENROLL_CSR_STATES
RECEIVE_CSR_STATES
DOWNLOAD_CSR_STATES
UPLOAD_CSR_STATES

Exporttracking
--------------
- FLAG_EXPORT_STATE is added to $object->{parsedItem}->{HEADER}->{FLAG_EXPORT_STATE}
- -1 exported but not commited
- 1 exported and commited
- 0 value means the object was not handled
- default is 0
- add this flag to the searchable attributes of every cryptoobject
- fix OpenCA::DB
- fix OpenCA::DBI
- HowTo
- if object is ready for export and FLAG_EXPORT_STATE is not -1 or 1
then
export it
set FLAG_EXPORT_STATE to -1
- if object is present for import
then
write serial to EXPORTLOG/OBJECT.LOG
if import is allowed (perhaps STATE_INJECTION)
then
import object with parameter for ALLOW_STATE_INJECTION
- if export is performed
then
mv EXPORTLOG/ to export
create new directory EXPORTLOG/ with appropriate files
- if import is performed
then
for every EXPORTLOG/OBJECT.LOG
read serial
load object
set FLAG_EXPORT_STATE = 1
update object in database
load all objects with FLAG_EXPORT_STATE == -1
set FLAG_EXPORT_STATE = 0 (export failed)
update object in database
- OBJECT.LOG can be REQUEST.LOG, CRR.LOG, CERTIFICATE.LOG, CRL.LOG, CA_CERTIFICATE.LOG

This is one of the most important changes for the future. So any
comments please?

Michael
--
-------------------------------------------------------------------
Michael Bell Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email: [EMAIL PROTECTED]
Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax: +49 (0)30-2093 2959
10099 Berlin
Germany http://www.openca.org



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel

Reply via email to