Hi, following up our discussion in the CRL serial thread:
>> - 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. And it's even not very useful, as it does not help in creating a certificate chain. >> - 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) No comments on this? I think this is the most important change, the other stuff is more or less cleanup and avoidance of redundancy. >> 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. Yes, you can keep it NULL. But then why not remove the attribute...? >> - 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. you are right, but I was not sure if we can associate an AUDITTRAIL entry with all required objects that need to have auditing entries. >> - 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. Yes, you are probably right. What I don't understand: how do you associate e. g. a key or some data with a certificate? Don't we have to have a foreign key, such as PRIVATE_SERIAL or DATA_SERIAL in the CERTIFICATE table as well? Another thing is that (in my opinion) we should be careful not to mix internal IDs with externally visible serial numbers. The CRL serial number, for example, can of course be used as an index to the table, but only in conjunction with the INTERNAL_CA, otherwise it would not be unique. In my understanding, SERIALs would only be unique within the same INTERNAL_CA. cheers Martin ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ OpenCA-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-devel
