> So how would protection against such "bad data" be done at the database
> level?
If you know it's a CA cert repository, you can require that the issuer
already be in the database.
If this a deferrable constraint, you can still add root certs (e.g., to
populate the database.) But if you remove the 'deferrable' attribute
then you can't add new root certs at all!
Of course a knowledgeable attacker with sufficient rights would just
alter table certs drop constraint ca1;
insert into certs values (bogo-root-cert);
alter table certs add constraint ca1 check (
foreign key(issuer) references certs(subject));
but you can watch for that with a cronjob that periodically checks the
database for root certs with unknown keyids. Since these should change
so infrequently, the values can be hardcoded.
(Or the truly paranoid could even put that into the database code itself -
it would not be hard to modify my postgresql code so that it only accepts
self-signed certs with keyids from another table and/or a hardcoded list.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
