ACTION-382: Generic techniques for trust root changeover

A new Certificate Authority (CA) have one major problem when entering the  
market: No presence as a pre-shipped trust root in deployed user agents  
(UA). This leads to problems for users accessing sites authenticated by  
the CA.

All UA vendors have strict requirements that a CA have to pass before  
their root is added to the trsut root store. Most such requirements  
includes having successfully completed a Webtrust audit (or equivalent), a  
costly and timeconsuming process. The process of contacting vendors is  
also a timeconsuming process, and there is also a significant deployment  
period before a trust root has good enough penetration in all user agents.

This is even a problem for "entrenched" CAs when they (for some reason)  
have to deploy a new root, and although they usually start the process  
with several years lead time, doing so is not always possible. This is  
currently the situation for CAs that have started to issue Extended  
Validation (EV) certificates. Due to several reasons it was not possible  
to enable EV for roots already installed in Windows XP, which again meant  
new roots had to be created and distributed to clients; without causing  
certificate verification problems for previous clients.

Both these problems can be solved by creating a version of the root  
certificate that is "cross-signed" by another, more widely deployed root.  
That is, a CA already deployed in a large number of UAs creates a  
certificate with the same subject information as the new root, and signs  
it from its root.

This creates a certificate chain that leads up from the end (Site)  
certificate to either the new root, or to the older root, depending on  
which trust roots the UA includes, but the client will be able to validate  
the certificate as long as it has at least one of the trust roots.

The primary problem with such cross-signed certificates is that they must  
be installed correctly on the server, so that the server actually sends  
all the intermediate certificates to the client, so that it is able to  
verify the chain.  Sites missing the intermediate certificates will cause  
some clients to inform the user about "unknown signers", and thus reduce  
the usability of the site.

This configuration problem is also an issue for any CA using intermediate  
CA certificates (which is true for almost all CAs and roots as of 2008),  
and can to some extent be reduced by clients that support automatic  
download of intermediate CA certificates at a URI location that may be  
specified in the certificate (the Authority Information Access field, AIA).

The problem is, however, more severe for cross-signed certificates since  
the certificates signed by the associated root/key usually do not include  
the AIA field, and including it may even not be permitted by PKIX.

Therefore, websites installing TLS server certificates issued by CAs using  
intermediate CA certificates, and/or cross-signed CA certificates MUST  
install all the intermediate CA certificates, to ensure that all clients  
can access the site without undue problems. Certificate Authorities SHOULD  
provide sufficient installation guidelines, and automatic utilities to  
verify correct installation of the certificates.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Monday, 11 February 2008 18:31:32 UTC