Implementer's notes

For some time now Opera has supported the Certificate Status Request Extension to TLS, although we did have a false start which was fixed in Opera 9.26.

What this extention does is to provide a way for a client to ask the server to do the OCSP revocation check for its own certificate, rather than the client doing a separate connection to the issuer's OCSP responder. The benefit of this policy is that the client saves time completing the connection since it does not have to wait for the OCSP responder. Also, if the server stores the OCSP response for a while, then the traffic to the OCSP responder becomes much lower (and much less expensive). Mostly servers will request updates and not all the clients visiting the site. This is called TLS OCSP stapling.

This mechanism only works for the server's own certificate. It does not work for any of the other certificates in the chain, and these days most Certificate Authorities (CAs) use at least one intermediate certificate, and some use four, or more. Today all the revocation information about these are retrieved using CRLs, not OCSP. This means that the information is not as up-to-date as is possible for OCSP, as CRLs (particularly for intermediates) are valid for much longer periods than OCSP. This may not be an issue today because most intermediates are controlled by the CA or other relatively big CAs, but it could become a problem if CAs start issuing large numbers of intermediate CA certificates that they do not control, for example to corporate customers. This might become a possibility if/when better domain limitations are widely implementated in browsers. If one of those corporate customers or an independent sub-CA starts issuing bad certificates, it is imperative to be able to revoke those CA certifiates quickly, which would be difficult if the CRL was updated every 12 months. On the other hand, OCSP responses are usually valid for less than a week.

Some intermediate CA certificates are now issued with OCSP URLs specified, but no browsers are currently using them. It is my recommendation that they do not start using them. The reason is that for all clients to use OCSP to check intermediate CA certificates would increase traffic to those
servers multifold, perhaps dozens of times when TLS OCSP Stapling becomes widespread, meaning the bandwidth cost for the CA will increase significantly. A number of CAs have already been concerned about the cost of supporting OCSP just for server certificates while waiting for stapling to become widespread; they would not like the cost of supporting OCSP for one or more intermediate certificates.

The solution, of course, is to expand the TLS Extension to support multiple OCSP responses, which should have been a fairly straightforward task, which it was for the handling of the responses. It turned out, however, that it was not practical to use the existing Certificate Status Request extension in TLS, since it does not allow multiple methods to be specified (but only a single method), which would be necessary to support servers that do not support the new response format. The limitation is due to both a hard restriction in TLS, as only one entry for a given extension can be sent in any extension list, and the request extension only permits a single format to be specified, not multiple.

The solution in the end was to create a new extension that permits multiple formats to be specified, not just a single one as before.

I have just submitted an Internet Draft to the IETF TLS Working Group defining such an extension and new response format. The draft is based on the existing definition with enhancements for the new requirements.

I hope the TLS WG will take on the work to help me complete the draft so that we can get this new functionality into all new clients and servers as soon as possible.

Comments intended as contributions to the draft should also be posted at the TLS WG mailing list.

draft-pettersen-tls-ext-multiple-ocsp-00.txt (archive)

I've once again refreshed my HTTP Cookie and Cache related Internet Drafts. The drafts have been discussed here a couple of times before, but to summarize:

draft-pettersen-dns-cookie-validate-04.txt (archive)

This Draft describes Opera's current heuristical approach to avoid sending cookies to registry-like domains like co.uk (The "Cookie Monster Bug"). First discussed here.

draft-pettersen-subtld-structure-04.txt (archive)

This Draft describes an improved approach to handling the "Cookie Monster Bug", using an online black list of registry-like domains. Also first discussed here.

The Mozilla team's work on "Effective TLDs" is based on an early version of this suggestion. The result of this work is now available from PublicSuffix.org, and is AFAIK currently used for one or more features by Chrome Beta, FF3, and IE8 Beta.

To reduce the complexity of the specification, and to avoid excluding possible solutions, I have now removed the previous suggestions for how the repository should be generated, and just shortly mention some possibilies in the Appendixes.

draft-pettersen-cookie-v2-03.txt (archive)

This Draft describes the ideal solution to the "Cookie Monster Bug", that everybody starts using a new format for cookies that completely remove the problem. First discussed here.

draft-pettersen-cache-context-03.txt (archive)

This Draft describes a method for giving sites a method to tell the client that a group of webpages are related, which can be used to better organize logouts. First discussed here.

draft-pettersen-dns-cookie-validate-04.txt
draft-pettersen-subtld-structure-04.txt
draft-pettersen-cookie-v2-03.txt
draft-pettersen-cache-context-03.txt

Last week at the W3C's Web Security Context Working Group's meeting at Opera HQ here in Oslo we discussed what should be the criteria for displaying the Extended Validation (EV) indicator, or the Augmented Assurance (AA) indicator, as the WG has decided to call this technology.

As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.

The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.

The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.

In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.

We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.

As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:

Today we're releasing the first Kestrel Weekly with Extended Validation (EV) support.

As I've written before, Extended Validation is a new way to indicate, in a Web site certificate, that the identity of the company behind the Web site has been verified according to a rigorous standard. The guidelines for this process is defined by the CA/Browser forum, which is a group consisting of many certificate issuers (CAs), browser vendors, and others.

We are now ready to start public alpha testing.

So, how does it work?

When a Web site is recognized as an EV site, Opera will change the background color of the security toolbar to green, instead of yellow as it is for normal secure Web sites. There will be a few further adjustments done in this area, the most major being that we have stopped displaying the Organization Name field and country in the security toolbar for non-EV sites, because this name might not have been properly verified for non-EV certificates.


What is required to be permitted to issue EV certificates?

Root CAs that want to issue EV certificates must first pass a rigorous audit to prove that they have the proper procedures in place to identify accurately the company requesting a certificate, and that this company is in control of the given server. Further, an agreement between the Root CA and the browser vendor is required before the browser can recognize the CA's certificates as EV certificates.

How does Opera know it is an EV certificate?

All EV certificates contain an identifier (called an EV-OID, actually a Certificate Policy identifier). The CA will insert this identifier when it has verified all the information. Only certificates issued from specific Roots are allowed to use these identifiers.

How does Opera know that a Root is allowed to issue EV certificates?

Each Opera instance will regularly download a digitally-signed list identifying the CA, its certificate, and which EV-OID(s) it is permitted to use (different CAs can use different EV-OIDs). When Opera verifies a certificate issued from this Root, it will "sift" through the data where the EV-OIDs are stored to see if it contains one of the EV-OIDs recognized for this Root. If such an EV-OID is present, Opera will proceed to check if the other requirements (see below) for saying the Web site is an EV site are fulfilled.

What is required by a Web site to be considered an EV site?

The primary requirement is, of course, that it is eligible to get an EV certificate, and that it has purchased and installed one. The certificate, and all the intermediate certificates must (of course) still be valid, and cannot have been revoked by the issuer (we now check both OCSP and CRLs). Further, there must be no problems verifying the certificate; that is, there must be no unknown issuers, no mismatch of server name, and no weak encryption.

There are also a couple of specific encryption key requirements: The Web site's key should (for RSA) be at least 2048 bits long, but non-root certificates which expire before 23:59:59 UTC/GMT December 31, 2010 MAY use RSA keys of at least 1024 bits. Except for the Root key, which (for RSA) must be at least 2048 bit long, all signing keys must be at least as long as the key of the certificate it is used to sign.

And lastly, if the Web site includes content from other Web servers, those servers must *also* be hosting EV-sites. This is a point at which we are much stricter than the other EV-capable browsers currently. As I said earlier: "It ain't EV 'til it is EV, all EV".

The reason for this requirement is that these other servers may provide content that directly controls the appearance of the entire site, either through frames or external Ecmascript embedded in the page (and the latter has full control of the site's content).

Considering how many click-wrap licensed Web services (such as for Web statistics) there are, it is not likely that the Web designers signing their sites up for these services will have done anything close to good-enough legal identity check of the service. Also, don't forget all the liability disclaimers such contracts include. It is impossible to check the contracts, but we can check that the sites have been able to get an EV certificate.

EV is intended to give you better information about who provided the content with which you are viewing and interacting. If not all the servers providing the content are providing this kind of information, do you really know who provided the important part of the content? Our answer is that you don't, therefore such sites, which at the moment include Paypal.com, will not get the EV indication unless they either remove all references to the non-EV content, or those providers upgrade to provide EV content, as well.

Which Root CAs are currently recognized as issuing EV certificates?

During the test period starting with this release we have provisonally configured three Roots as EV Roots (in alphabetic order)

• Entrust's EV Root
  
• GlobalSign's EV Root
  
• VeriSign's G5 Class 3 (EV) Root
  

Other CAs and Roots may be added later.

About the online repository

As mentioned above, Opera retrieves information about which CAs are recognized as EV-issuers from an online repository. This repository, hosted at https://certs.opera.com/, contains a digitally-signed file listing all the EV issuers and a (separately) signed list of the EV-OIDs they are using.

This repository is refreshed every 6 hours, so we can start updating clients very quickly. At present Opera will check this repository immediately when it starts, but the final version will only check once a week at the same time as we check for other updates.

Examples of EV sites

• https://www.dnbnor.no/
  
• https://nettbank.sparebank1.no/
  
• https://healthcare.searchamerica.com/
  
• https://taxcube.kpmgabogados.es/
  
• https://meine.deutsche-bank.de/mod/WebObjects/dbpbc.woa?lang=en
  
• https://ev.globalsign.com/
  

One of the new SSL/TLS features we added in 9.0 was the TLS Certificate Status Extension, which is essentially asking the TLS server to do the revocation check for its own certificate (OCSP), thus telling the client whether or not the certificate it presents is valid.

At first this can look pretty much like putting the fox to guard the henhouse, but there is no real danger as even a malicious server can't get away with sending the wrong data for long. This is because the status information is generated and signed by the certificate issuer (CA), meaning it can't be faked, and is only valid for a few days at most, reducing the window of opportunity to a minimum.

The primary reason for using this method is reducing the traffic load on the OCSP servers. Once all clients support OCSP the load on those servers will be tremendous, so it is prudent to look at solutions to reduce not just the network load on the CA's servers, but also the time used to check the validity of the certificate. It is a fact that making a direct OCSP check takes time, and that it increases the time to establish a connection, slowing down the user's surfing.

Therefore, using the TLS server as a proxy makes sense, and we introduced it in 9.0.

Unfortunately, it turned out that the implementation had a problem. Due to a mistake in the way the Extension was read, a method introduced in 9.0, Opera 9.0 to 9.25 will crash when the server tells it that it will send the status message.

This showed up only when Microsoft started testing its Windows 2008 server (IIS 7), due to be released this month.

Unfortunately, it was not until less than two weeks ago I learned of the problem, when Microsoft contacted me directly with a testcase (Thanks). It didn't take me long to find and fix the problem, but it still requires releasing a new Opera version.

In this case I will strongly recommend that users of Opera 9.0 to 9.25, inclusive, upgrades to the upcoming Opera 9.26 (Update: It is now available), due to be released later this week (but an RC is available). The next 9.50 weekly will also contain a fix for the problem. In particular, you should upgrade if your installation crashes when it tries to connect to an SSL/TLS/HTTPS site.

We apologize for the inconvenience, in this case we were a little bit too far out on the (b)leading edge.