Re: [TLS] OCSP must staple

Yoav Nir <> Thu, 12 June 2014 09:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EAA6E1A0460 for <>; Thu, 12 Jun 2014 02:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 27jS-8Yg65Yc for <>; Thu, 12 Jun 2014 02:02:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9255B1A0199 for <>; Thu, 12 Jun 2014 02:02:46 -0700 (PDT)
Received: by with SMTP id t60so951675wes.0 for <>; Thu, 12 Jun 2014 02:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nBnRFsiGorogVNcGOrYwwGYadfO5V85EiV9HlqYiPeA=; b=TLHTkFr81jJz86YNwirwLXEMLIpX/FfVtjeBKf9bbxewykvb319bThESLbgZ3oG196 HSH5L/cGxr8VZ0/pI1tBgMJKcX7gsny8Yj0ByarvRNSAGVUnoYIuBBBbeO8M74/j8Vep Wy37vbPInlDOW8nem8XoLDA+fpYAZA31ibNGboAr9HmfH79si/yvSeNRHmyLhjw0Kp6s EgGfIdywNFWSQZJQks1yIZYX7p0WhnpQhnVSa5gnTzp8c6FBsExPf+q+J6lPuBHWHooC 2nTENO+pEZk3gyvWqkXZVHlDMPMTfK+TPBcq1tB5xByULV07G/F0Aq1J5EUsDDE2Hi+a y34A==
X-Received: by with SMTP id d18mr1085916wib.49.1402563763781; Thu, 12 Jun 2014 02:02:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ht5sm557687wjb.49.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 02:02:43 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_80EF5F42-AE9E-4F1D-ADBC-94884E529748"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 12 Jun 2014 12:02:40 +0300
Message-Id: <>
References: <> <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <> <> <> <> <>
To: Brian Smith <>
X-Mailer: Apple Mail (2.1878.2)
Cc: "<>" <>
Subject: Re: [TLS] OCSP must staple
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jun 2014 09:02:49 -0000

Hi, Brian

Interesting stuff. Also good to hear that it’s easy to implement, although mileages vary.

Regarding TLS proxies, I can give my perspective, as I work for one vendor. 

<hat type=“vendor” status=“on”>
Our fake certificates contain the DNs and alternate names from the original certificate. We don’t copy over any extensions that we don’t understand. The same is also true of TLS - we don’t copy extensions we don’t know. That is what allows our proxy to gracefully downgrade HTTP/2 or SPDY clients and gateways to HTTP/1.
As for dates, these *are* copied from the original certificate, the reason is that this makes the client behavior similar to whatever it is with the original certificate. We did consider making the certificates short-lived, but decided against it. 

So your proposed heuristic for detecting fake certificates will work with some proxies, but not all. Adam’s suggestion should work better, but best is if the fake certificate doesn’t promise things the proxy CA doesn’t understand.


On Jun 12, 2014, at 1:49 AM, Brian Smith <> wrote:

> On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns <> wrote:
> On 6/5/2014 3:12 PM, Brian Smith wrote:
> Is it really significantly easier for CAs to add new certificate policies compared to adding new certificate extensions? I could see how that could be the case, but I think it would be good to hear from CAs about this.
> Mostly the "put a policy object in the ca certificate" reduces to "configure the text string of the OIDs you want to include". for example.
> The certificate policy extension is pretty well formed, which means that its pretty easy to specify in configuration language (e.g. xml, label=value) what you want to be included rather than having to go back and add new ASN1 encode/decode/translate to and from string logic.  Things like Dogtag and EJBCA support it via a gui
> I have researched some of the pros and cons of Michael's policy-based approach. I also implemented it in a private copy of mozilla::pkix and Firefox. In particular, I made it so:
> * When the extension is present in the end-entity certificate, that a valid "Good" OCSP response must be provided in the TLS handshake,
> * There will never be any fallback to OCSP fetching or CRLs or cache lookups when the end-entity certificate has the must-staple policy. However, additional certificate trust information (blacklists/CRLSet) are still consulted.
> * The modified mozilla::pkix will never build a path from an end-entity certificate or sub-CA to a higher-level CA certificate where the higher-level CA certificate has the Must-Staple policy but the end-entity or lower-level sub-CA certificate doesn't have the Must-staple policy.
> * My modified mozilla::pkix enforces a maximum OCSP response lifetime of 2 days + slop (1 day) = 3 days if Must-Staple is present, instead of 10 days.
> The good news:
> * In mozilla::pkix and Firefox, it is just as easy to implement Machael's policy-based approach as it would be to implement the approach outlined in the draft.
> * As Michael said, most if not all CA software already supports custom certificate policies, so there is *no* new code required on the CA side for Machael's approach. This is a significant advantage, especially because there are a lot of companies that have purchased sub-CA certificates that chain to publicly-trusted CAs, which use closed-source software (e.g. Microsoft's). Basically, with Michael's approach, everybody would be able to use Must-Staple straight away, if they want to, without writing code.
> The bad news:
> * TLS intercepting proxies cause trouble. In particular, some (if not all) versions of Microsoft Threat Management Gateway forge their fake certificates by copying the certificate policies from the original certificate that they are trying to impersonate. Yet, Microsoft TMG does not support OCSP stapling or in fact any kind of OCSP. Consequently, it will copy the Must-Staple policy into the forged certificate but it won't staple a response. I imagine other TLS intercepting proxies will do the same.
> * It is unclear what TLS intercepting proxies do with certificate extensions that they don't understand. I would guess that some copy those extensions into their forged certificates and others do not.
> The OK news:
> * From what I've found, Microsoft TMG forges certificates that are very short lived (24hrs). Thus, if we make an exception that short-lived certificates (<= 48 hours) with the Must-Staple feature do not need to have a stapled OCSP response even with Must-Staple, we can probably avoid a lot of the issues with TLS intercepting proxies, regardless of how the Must-Staple feature is encoded in the certificate.
> Thus, for ease-of-deployment reasons, I prefer Michael's policy-based approach + the short-lived certificate exception over the approach in the draft that uses a new extension. Regardless of which of those two approaches is taken, we'll need to do a lot of interop testing with various kinds of TLS intercepting proxies.
> Cheers,
> Brian
> _______________________________________________
> TLS mailing list