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)

The Opera Security group just got its own home page.

"Security @ Opera" is where we will post information about security advisories, as well as occasional articles about security related topics.

The first article is about the recent developments concerning MD5 in SSL/TLS certificates.

Today we have formally EV-enabled the first two CAs.

For more information, please see The Rootstore's announcement

We have now created a homepage for the Opera Root Certificate repository: The Rootstore.

The Rootstore will be where we announce updates and general information about the root repository.

If you are a Certificate Authority, or generally interested in Opera's certificate store, The Rootstore will be the place to watch.

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: