One thing that made EJBCA painful was that there was no clean way to actually delete certificate or chain history. The system held onto everything forever and cleaning up was hard. CryptOS should let an operator genuinely delete or purge certificate and chain history, for example removing a retired or mistaken chain and the records of what it issued, rather than only hiding it.
There is a tension to design around, not a blocker. CryptOS keeps an append-only, hash-chained audit log on the encrypted state partition, and a PKI needs some retention for revocation to stay correct. So "delete history" has to be defined against those. A reasonable shape is to purge the issuance and inventory records and retired chains while either preserving or explicitly rotating the audit chain, behind a guarded, operator-confirmed action that is itself audited. A soft delete followed by an explicit hard purge, scoped to a chain and its leaves, would fit.
The goal is that an operator can retire and remove old or mistaken CAs, chains, and their certificate history cleanly, which is the thing EJBCA makes hard.
Not scheduled. The retention and purge policy, how this interacts with CRL and OCSP, and whether the audit chain is preserved or rotated on purge are still open.
One thing that made EJBCA painful was that there was no clean way to actually delete certificate or chain history. The system held onto everything forever and cleaning up was hard. CryptOS should let an operator genuinely delete or purge certificate and chain history, for example removing a retired or mistaken chain and the records of what it issued, rather than only hiding it.
There is a tension to design around, not a blocker. CryptOS keeps an append-only, hash-chained audit log on the encrypted state partition, and a PKI needs some retention for revocation to stay correct. So "delete history" has to be defined against those. A reasonable shape is to purge the issuance and inventory records and retired chains while either preserving or explicitly rotating the audit chain, behind a guarded, operator-confirmed action that is itself audited. A soft delete followed by an explicit hard purge, scoped to a chain and its leaves, would fit.
The goal is that an operator can retire and remove old or mistaken CAs, chains, and their certificate history cleanly, which is the thing EJBCA makes hard.
Not scheduled. The retention and purge policy, how this interacts with CRL and OCSP, and whether the audit chain is preserved or rotated on purge are still open.