Jeff, what you describe is similar to the concept of a "validation
authority", which has been around for a while. A VA service has a
contractual relationship with RPs, and is responsible for responding on
trustworthiness of certificates (and/or signatures). XKMS/SCVP/DSS
protocols support this concept. There is at least one commercial entity
(our partner DNV), which is offering such a service currently:
http://www.dnv.com/services/verification/vas/index.asp
Importantly in addition to validating the trustworthiness of the
certificate, DNV also offer a security quality rating for the certificate
(based on the CA's audited policy/practices, hash and public key algorithms
used and key lengths etc.). Such a quality rating service is important in
examples like this where a certificate is trusted because it chains to a
trust anchor, but is not considered acceptable because it fails a minimum
quality rating required by the RP.
However although Ascertia offers products which interface with Validation
Authority service providers, the standard browser is not yet capable of this
and is unlikely to be for some time.
Regards,
LK
-----Original Message-----
From: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org] On
Behalf Of Jeffrey Hutzelman
Sent: 08 January 2009 09:45
To: Peter Gutmann; v(_dot_)paz(_at_)uq(_dot_)edu(_dot_)au
Cc: tmiller(_at_)mitre(_dot_)org; ietf-pkix(_at_)imc(_dot_)org;
ietf-smime(_at_)imc(_dot_)org; cfrg(_at_)irtf(_dot_)org;
saag(_at_)ietf(_dot_)org; jhutz(_at_)cmu(_dot_)edu
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate
--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