[Top] [All Lists]

RE: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

2009-01-08 02:47:37

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:   

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.  


-----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

--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