--On Thursday, January 08, 2009 05:21:22 PM +1300 Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
Even then it's a rather indirect approach that doesn't really target the
guilty party since you're scaring the user who is supposed to exert
pressure on the site which is then supposed to pressure the CA for a fix.
This cuts to the root of the problem: there are no contractual relations
between a relying party and the cartificate authorities upon whom he
relies. As a result, there is no incentive for certificate authorities to
adopt practices which benefit the relying party. Instead, the incentive is
to adopt practices which benefit the CA and its customers, which are the
parties to whom it issues certificates (but _not_ the parties to whom only
other CA's issue certificates).
Perhaps a solution to this is a new model. Under the new model, each
relying party who chooses to participate would punt the trust anchors that
come with his or her browser or other software, and instead subscribe to a
trust anchor service, which for a fee provides a regularly-maintained list
of trust anchors, or perhaps a single trust anchor which signs "root" CA
certificates and for which a well-maintained OCSP server is provided. Such
a trust anchor service would be an obvious candidate for bundling with ISP
services or for sale by security software vendors.
The trust anchor service, then, reaches agreements with the various
certificate authorities, under which the CA is included in the list of
trust anchors in exchange for the CA agreeing to maintain practices which
are acceptable to the trust anchor provider. Note that some browser
vendors already do essentially this, except that the CA has no contractual
obligation to the browser vendor to meet the cirteria for inclusion in the
trust anchor list on an ongoing basis, and the browser vendor has no
contractual obligation to the users of its product to include only those
CA's which meet a suitable set of criteria.
-- Jeff