Posts Tagged ‘CRL’

IETF 86 – Web PKI Working Group

Friday, March 22nd, 2013 | Bruce Morton

At the IETF 86 meeting in Orlando last week, there was a working group meeting discussing the operations of the Web PKI. At the previous IETF 85 meeting a birds-of-a-feather was held to discuss the purpose of having such a group. The result of the meeting was an established group with the charter that states purposes such as:

  • Working group will work to improve the consistency of Web security behavior
  • Address problems as seen by the end-users, certificate holders and CAs
  • Describe how the Web PKI actually works
  • Prepare documented deliverables as discussed below

The meeting discussed the charter and the four following deliverables. More information is in the presentation slides; look under the Operations and Management Area, then under WPKOPS.

Trust Models

The trust model document will discuss how the root store providers support the trust between the end entities Web server and the relying party’s browser. The CAs play a trusted third party (TTP) in the model where they comply to the root store providers certificate policy, provide certificates to the end-entities and provide certificate status to the relying parties.

What makes the case interesting is that there are many parties in each role in the model. The trust model for the Web PKI has to consolidate certificate policies from many root store providers. The trust has to work for many servers and many browsers. There are many CAs globally providing TTP to the model.

The document will discuss the basic model and the variants for how the roles are adapted to the real world.

Certificate Revocation

Certificate revocations will be reviewed to see what CAs issue, whether end-entities provide revocation data and how relying parties handle revocation.

Revocation data is provided by certificate revocation lists (CRL) and OCSP, including OCSP stapling. The distribution points for this data are included in the SSL certificate.

OCSP, as deployed, is also interesting. The group wants to know what trust anchors are accepted and what certificate extensions are set, such as key usage, extended key usage and policy OIDs.

Field & Extension Processing

With many CAs issuing certificates and many browsers and Web servers using certificates, we all want to know what is in them and how are they handled. The problem is inconsistent behavior. From a support point of view, consistent behavior is less confusing and easier to maintain user satisfaction.

To develop the document, researches are using six different user agents installed on 30 operating systems to test 300 conditions. The goal will be to use cross-sourcing to find the broad areas of matches and mismatches, then perform specific testing to focus on the confusing areas. The data will be tabulated on spreadsheets through Google Drive and made freely available to interested parties.

The project is still at the beginning where the conditions list, platforms/OSs and user agents still need to be determined.

TLS Stack Operation

There are common PKIX issues with the TLS stack, such as no chain to trust anchor, non-matching names, expired certificates and expired CA certificates.

The document will cover TLS protocol tweaks to common SSL libraries to achieve interoperability. It will address how alerts are provided to the relying party and the navigation bar use of long-lived icons and indicators. It will also discuss PKI-related choices made by the relying party.

Moving Forward

Development of the documents will take about two years to complete. Once completed, the data will help industry standard groups and developers improve the use and security of PKI implementations. Hopefully, this will translate to a more pleasant and secure browsing experience.

SSL Certificate Status Checking

Tuesday, March 12th, 2013 | Bruce Morton

As part of its effort to promote SSL certificate best practices, the CA Security Council (CASC) has offered a couple of blogs on the importance of revocation checking, categorized in Part 1 and Part 2.

Here are my summaries of SSL certificate status checking.

What is the purpose of a CA-issued SSL certificate?

  • To bring trust to the end-user of who controls the website
  • The CA-issued SSL certificate brings encryption as well, but so do self-signed certificates; self-signed does not bring trust
  • Trust is elevated based on the verification practice used to validate the certificate applicant:
    • Domain Validation (DV) verifies the domain name is controlled by the applicant.
    • Organization Validation (OV) verifies an identity that controls the validated domain.
    • Extended Validation (EV) verifies the identity and authorization of the applicant at a higher level.

Why revoke a certificate?

  • Changes by the website owner (e.g., no longer in business, does not own domain, changed organization name)
  • Private signing key is compromised by a third party
  • CA learns that information in the certificate has changed or has been misrepresented

How is a certificate status conveyed?

  • Certificate Revocation List (CRL) – A digitally-signed file containing a list of certificates that have been revoked and have not yet expired
  • Online Certificate Status Protocol (OCSP) – A protocol in which the client requests the status for a particular certificate signed by a particular issuer, and receives a digitally-signed response containing its status
  • CRL and OCSP responses can be found at a website address included in the certificate

What could happen if you go to a risky site?

  • Loss of Private Information – An attacker controlling the risky site could capture your personal information such as your birth date or credit card number
  • Identity Theft – An attacker could capture your username and password, allowing them to impersonate you on a website
  • Financial Loss – Loss of your credit card number or username and password could mean financial loss
  • Malware Installation – An attacker could install malware on your computer to help steal other information or take over your computer for a larger attack

How do I check certificate status?

  • Certificate-status checking is done by your browser or other certificate-aware software
  • In some cases, you may need to ensure certificate-status checking is turned on. This is more likely for software using Windows XP as an operating system.
  • Browsers and applications provide dialogue boxes to turn on certificate-status checking, see below

Windows 7

Firefox

Java

Short-Lived Certificates

Tuesday, August 21st, 2012 | Bruce Morton

Certificate revocation is a current SSL industry issue. There are many causes to the problem. Some end-users do not have certificate-revocation checking turned on. Browsers support CRL or OCSP, but in some cases not both. The certification authorities (CA) may not provide reliable revocation responses. And what if there are no revocation responses from a CA; should there be a hard or soft fail?

One result is the CA/Browser Forum is looking into revocation to see what can be done to improve the situation. Another result is that the short-lived certificates are now being discussed.

A short-lived certificate is issued for a limited validity period, say seven days instead of one year. The certificate is re-issued every few days, so that the subscriber can update the certificate on their server on a continuous basis. The technical difference is that the short-lived certificate would not have any information about where revocation data can be found. If there is a breach that requires certificate revocation, then the CA would just stop re-issuing the certificate.

Revocation would be complete within the validity period of the last certificate issued. In this case, the period would be seven days, which is also the same validity period of a typical CRL or OCSP response. The result is 100 per cent revocation, as all browsers provide a trust dialogue on expired certificates.

A study has been prepared by a group of Stanford and Carnegie Mellon University researchers. Their conclusion was short-lived certificate complement the CRL by adding security when software updates do not make sense (e.g. mobile platforms), rebalances power between browsers and CAs and removes Google as a single point of failure. In the case where a CRL is not supported, short-lived certificates provides the security guarantees equivalent or better than OCSP. Short-lived certificates are fully backwards compatible, incrementally deployable, impose no performance penalty, and add another layer of protection to Web users.

The study authors reference Google and Chrome, as Google has declared that Chrome will not use CA provided revocation information.

Is this the answer for everyone? No, primarily it’s a solution for highly technical certificate subscribers with a high-value Web domain that can update their certificates on a continuous basis. It is unlikely that this solution will be implemented by smaller users until Web servers support methods to continuously update the SSL certificates or until Web-hosting providers support the solution.

You don’t have to worry about short-lived certificates yet. The CA/Browser Forum Baseline Requirements specifies that SSL certificates support CRL and OCSP. If the concept is accepted, I’m sure there will be a proposal to update the requirements to allow short-lived certificates.

If You Don’t Like Your CA’s Practices, Find One More Sympatico

Tuesday, April 24th, 2012 | Jon Callas

The following Mozilla bug came my way via the Cryptography mailing list.

The gist of it is that a Norton (né VeriSign) customer asked for a certificate with two-year certificate, and got one with six-year validity. I don’t precisely understand why the customer is complaining to Mozilla, but they didn’t get satisfaction with Norton, who wouldn’t do what they want.

I can understand the irritation. Norton has just assumed that the customer will continue buying for six years and has left what happens if they don’t as an eventuality. I’d hate it too if any supplier of mine just assumed that I’d keep buying. It’s an affront on the customer service side.

(more…)

Google Rethinks Revocation

Wednesday, March 7th, 2012 | Jon Callas

Google has decided in Chrome that they’re going to take a different approach to certificate revocation.

Chrome developer Adam Langley describes the decision in detail in his blog, Imperial Violet. Unlike a number of CAs, we think this is a pretty good idea, even if incompletely executed so far.

Revocation is a difficult task. It is difficult because it requires coordination between the CAs and the browsers to protect the end user, and that the event is definitionally unusual. An end user sees an actual revoked certificate only once in millions or billions of web fetches. The checks are time-consuming as well. Langley says that the median time of a successful check is about a third of a second and the mean is over a second. (more…)