The Opera Rootstore

GlobalSign have added a SHA-256 signed Root to the repository. This is a step preparing for a future changover to using SHA-256 when signing certificates. Currently there are no test sites available.

As mentioned earlier when we updated two of their certificates, Verisign have been updating some of their certificates that were signed with MD2 so that they are signed using the more secure SHA-1 method instead. However, there were some problems with the Class 3 (G1) certificate chain as all the intermediate certificates issued by the Root were chaining to the old MD2 Root because they specified the serial number of that certificate. Therefore new replacements for the intermediates had to be issued as well.

Unfortunately, testing showed that at this time it is not practical to update older versions (9.5 and 9.6) to use this Root due to a bug in the certificate verification code (updating the older clients would "break the Web"). This combined with missing functionality in the repository language meant that to be able to use the new Class 3 Root we had to create a new version of the repository ("03") where the "02"-version's shortcomings have been fixed, which will be used by upcoming releases of 10.0. In the upcoming versions of 10.0 MD2 support will be completely disabled. Further down the road when "all" servers have been updated with the new intermediates we may replace the certificates for older clients, too.

The fourth RSA root signed with MD2 (the "RSA Secure Server Certification Authority" Root) is now being replaced in all 9.50+ builds, as it does not have the problems mentioned above. This certificate is also being phased out, so it is not going to remain in the repository for long; it expires early January.

Today, Verisign (including Thawte and Geotrust), and Comodo were formally EV-enabled in Opera v9.50 and later.

There are no practical effects for Comodo, as their certificate has been provisionally enabled for a few months as part of EV testing. Verisign's Thawte and Geotrust certificates, which were not part of the testing, are EV-enabled as of today.

TestURLs:

• Comodo:
  https://comodocertificationauthority-ev.comodoca.com/
  https://www.sslcertificaten.nl/
  https://secure.comodo.com/example.html
  
• Geotrust: https://www.geotrust.com
  
• Thawte: https://www.thawte.com
  
• Verisign:
  https://www.dnbnor.no/
  https://nettbank.sparebank1.no/
  

As usual, the EV certified Web sites signed by the newly EV-enabled Roots will not show the EV indicator until after the weekly automatic update (on start), or a manual Help->Check Updates (with a restart possibly needed afterwards).

We have several more CAs in the EV pipeline that are expected to be ready within a couple of weeks. Stay tuned.

In this information letter we will cover some recent news relating to the CA Root Store in Opera:

• Opera 9.50's new rootstore
  
• Opera 9.50 certificate revocation checking
  
• EV in Opera
  
• Process for EV-enabling roots
  

Opera 9.50's new rootstore

In Opera 9.50, which was released a few weeks ago, we introduced [URL= http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-faster-root-certificate-updates]a new system for distributing Root Certificates to Opera users.

Instead of users having to upgrade their installation in order to be able to use new Roots, they are now able to use the new roots within a week of the root being added to the repository.

This is achieved by storing all Roots in an online repository. Each client will regularly download an up to date list of available Roots from it.

Each installation now ships with only the most frequently used, and it will download and install Roots from the online repository as needed.

The repository index can also indicate that if a user has a particular certificate installed, then Opera should download another certificate as well. This is particularly useful during certificate rollover, and when a cross-signed root is used for Extended Validation.

The benefits of this approach are:

• Quicker time to market for new CAs
  
• Wider availabilty to users "immediately"
  
• No need for users to upgrade their client when new roots are added
  
• Reduced executable footprint for Opera, in particular on phones and devices.
  

All automatically downloaded content in the repository is digitally signed, as well as hosted on a TLS server to secure the system.

Opera 9.50 certificate revocation checking

Opera 9.50 includes two major changes to its revocation checking system: Support for CRLs, and using GET for OCSP instead of POST.

Opera has since version 8.0 supported OCSP for SSL/TLS using the POST retrieval method with a nonce. This method was not very cacheable between sessions, and was not proxy cacheable, and could therefore cause extra load on the CA's OCSP responder.

In Opera 9.50 we have changed to using the GET HTTP method without sending a nonce. This makes it possible for proxies to cache the response, as well as that Opera can more easily cache the response between sessions.

Opera 9.50 also added support for CRLs for SSL/TLS and will now download and cache CRLs for all non-root certificates, except those end certificates identifying an OCSP responder. Selection of CRLs for a verification is done based on the URL identified in the certificate.

If a certificate chain fails either CRL or OCSP verfication (but is not revoked) the associated website will not get a padlock indication, and the security toolbar will not be displayed.

Known issues:

• We have seen several OCSP responder from various vendors that does not correctly implement the GET method for OCSP. The vendor of the most widely responde have located the problem and developed a patch.
  
• If a certificate indicates a CRL that is not signed by the issuer of that certificate then CRL validation will fail, even if the correct CRL is cached.
  
• Some certificate chains have CRLs specified for some certificates in the chain, but not all non-root certificate. In these cases CRL validation will also fail.
  
• We have also seen some cases where the only CRL specified uses LDAP, not HTTP. Opera does not support LDAP, and thus CRL validation will fail.
  

Opera 9.51 have override capabilities for some of these cases, and 9.52 will expand those. To configure those overrides, detailed information about the correct URLs and certificates are needed for the CRLs.

More information about these problems and the workaround are available in this article.

Extended Validation in Opera 9.50

Opera 9.50 for Desktop is the first version of Opera to support Extended Validation (EV).

EV websites are indicated by turning the security toolbar green, instead of yellow as before. In this mode Opera will also display the website's Organization Name from the certificate.

Opera will once a week update information about which Roots are EV-enabled from the same online repository as the Roots are downloaded from.

For a site to get the EV indicator the following requirments must be met:

• All content displayed on the site must be downloaded over strong TLS connections
  
• All revocation checking must succeed.
  
• The EV-enabled Root must use an RSA key that is at least 2048 bits long
  
• Certificates using 1024 bit RSA must expire before Jan 1, 2011 (GMT)
  
• Except for the Root, intermediate certificates must use keys at least as long as the key in the certificate it is used to sign, and if one of the keys are longer than the roots,all of them must be longer. That is, a 2048 bit Root can sign a certificate with a 4096 bit key, but that key can only be used to sign certificates with at most 4096 bits.
  

Process for EV-enabling Roots

To EV-enable a root embedded in Opera a CA must have passed an EV-audit, currently by WebTrust. An authorized copy of this audit must be sent to Opera.

We also require the URLs to a number of sites (test or real) using certificates issued from the Root that is to be EV-enabled. These sites should demonstrate use of all relevant OCSP, CRL and AIA hosting servers so that we can verify that these services interoperate with Opera. Confirmation of this is necessary before a Root can be EV-enabled.

Once the qualification step is passed, EV-enabling require a legal agreement to be signed, and once these steps and the testing has completed, the root will be EV-enabled.

EV-enabling of clients will take about a week from the online repository is updated, until all installations have downloaded the update.

Please note that we have currently received a large number of applications for EV-status, and it will probably take a few months to process all of the applications.

Other changes in Opera 9.50

There are a number of other changes in Opera 9.50 that may be of interest to Certificate Authorities:

• Opera no longer support SSL v2.
  
• Neither does Opera support 40- and 56-bit encryption methods anymore. This also affects import of PKCS #12 files where these methods have been used.
  
• Opera now supports the Authority Information Access (AIA) extension in certificates, and is therfore able to download missing intermediate certificates. Once used to successfully complete a validated chain the intermediate is cached in the intermediate CA certificate store so that the CA's repository server is not overloaded by requests.
  

Other things of note in Opera are:

• Opera gives warnings to the user if a certificate in the chain, or other keys used in the key exchange is shorter than 900 bits for RSA, DH, and DSA.
  
• If those keys are shorter than 1000 bits no warning is displayed, but the "padlock" is not displayed for the site.
  

Both these limits can be adjusted by a preference that Opera Software can adjust via our automatic update system. The next steps on the ladder are 1020, 1100, and 1200 bits, after which both limits will move in steps of 100 bits, and 300 bits apart. Raising the upper boundary to 1020 bit is being considered, and we may raise the boundary to this level before the end of 2009, and while no decision has been made, it is quite possible that this limit will be raised further before 2012, which will affect all 1024 bit roots.

The goal of this system is to inform the user as accuratly as possible about how secure the connection to the server is.