Hi,
> I'm working on the CRL generation of the CVS HEAD. Some mails sound like
> the most people think that we should include a CRL serial into the CRL
> by default which is no problem. Question, does it be important that the
> sequence of CRL serials has no holes?
>
> Any ideas and arguments are welcome.
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).
*Topic change*
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.
Ideas:
- remove the CA_CERTIFICATE table
Reason: CA certificates are just ordinary certificates, see below
- 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
- 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
- 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
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).
What do you think?
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
