Martin Bartosch wrote:
I'd prefer to have no holes in CRL serials, because it might be required in certain environments that you are able to provide a complete track of CRLs. So I think we should consider extending the CRL table to include a CRLNUMBER attribute (then possibly use max(crlnumber)+1 and a DB transaction to assure that race conditions are not possible).
If the CRL has a serial then this is the normal serial in the database. Please see OpenCA::CRL. This was a fix for the ones who already use CRL serials. The only code which must be modified is getNewSerial. The code is simple:
CRL ==> return $self->listItem (OBJECTTYPE => "CRL", MODE => ROWS) +1;
*Topic change*
... cool subject for this topic ;)
In the CVS head database schema, we have ... "EXTERNAL_CA", "INTERNAL_CA", ... in every table. I have been thinking a bit about the database schema in CVS head and believe we might consider changing schema a bit.
Ok, let's see.
Ideas: - remove the CA_CERTIFICATE table Reason: CA certificates are just ordinary certificates, see below
Nice idea - usually the table only includes one certificate which means that there is a design bug.
- introduce a new table, e. g. CA
Purpose:
- identification and reference of CA certificate for internal CAs
- mapping between internal and external CAs
Attributes:
INTERNAL_CA: internal CA
EXTERNAL_CA: external CA this CA belongs to
CA_CERT_SERIAL: serial number of the CA certificate (foreign key to
the CERTIFICATE table)
Change the attributes for the other tables:
- table REQUEST: should include only the EXTERNAL_CA attribute,
remove INTERNAL_CA attribute
Reason: a request is issued from the outside. By definition from
the outside only the external CA is visible, OpenCA dispatches
the request to the matching internal CA itself based on the
CA cert validity.
- table CRR: see REQUEST
This is no problem because INTERNAL_CA is completely unused.
- table CERTIFICATE: should only include the INTERNAL_CA attribute, not the EXTERNAL_CA attribute. Reason: a certificate always belongs to one single internal CA - table CRL: see CERTIFICATE - table AUDITTRAIL: see CERTIFICATE
The table AUDITTRAIL belongs to requests too. I think the best way is to have no external and internal CA stuff in audittrail because the object reference is enough.
- table DATA: not sure, but I think same as CERTIFICATE - table PRIVATE: see DATA - table SIGNATURE: see DATA - table VOTING: see DATA - table DATAEXCHANGE: see DATA
A more radical idea, does it be necessary that other data than certificates and requests has external_ca or internal_ca flags? Perhaps the CRLs should be marked but all other data does not need such flags.
Other thoughts: We need some way to express certificate chains. An entry in the CERTIFICATE table could include a reference to the issuer certificate in the same table. Selfsigned certificates could point to themselves. This also means that the table can contain certificates that are not assigned to an internal CA (CAs outside the OpenCA installation's scope).
Do you want to import a complete PKI from another CA? I remember that you need this for management issues (one PKI for operator certs and one PKI for user certs). The serials are really problematic because they cannot be unique. Perhaps we must defined the primary index on another base (serial + external ca).
There is at minimum one recommendation let's split the mail tracks. The issues are complicated enough.
1. CRL serials 2. database schema 3. chains / foreign PKI integration 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
