I fail to see how our implementation does not meet this criteria?
Certificates are public information that can be moved around freely and
"easily" verified by anyone receiving them. Feel free to pass around
the "self-verifying" certificates from the TIS/PEM database.
Your implementation does not meet this criteria because the magic bit in
the database which indicates which keys should be trusted to end a
certification path, and which keys shouldn't, is *NOT* self-verifying.
Hence, while the certificates may be freely passed around, the
authorization information embedded in your key database is subject to
tampering.
In contrast, I can leave my PGP public key ring (i.e., the analogue to
your public-key database) anywhere and it is safe from tampering, as
long as I have a protected copy of my private key. Using PGP, I can
quickly and easily verify that the public key on my (possibly suspect
public key ring) corresponds to my trusted private key, and then at one
fell swoop, verify that all of the signatures on the public key ring.
Using your scheme, I have no way of verifying the authorization bit
stored in your key database, short of examining each one manually.
So for example, if I have write access to your key database, I could
spoof it completely, and put in bogus public key values for the IPRA,
the PCA's and then put in certificates which are signed by bogus private
key values of the IPRA's and PCA's. I can then then insert rogue
certificates again signed by the bogus private key values of the IPRA
and PCA, and you will have no way of verifying it, short of dumping out
the 1024 bits of IPRA public key, and manually checking it against a
printed copy of the IPRA public key. This is because TIS/PEM will
blindly believe that any certificate is the root, as long as it has the
magic bit set.
This problem is solved if you use a real certificate to sign all of your
"root" certificates with your private key, since you will much more
easily be able to verify your public key (because you have the private
component).
- Ted