Re: [TLS] OCSP must staple

Brian Smith <> Thu, 05 June 2014 17:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 787A01A024D for <>; Thu, 5 Jun 2014 10:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZgMat87RhKlq for <>; Thu, 5 Jun 2014 10:05:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C824E1A02A1 for <>; Thu, 5 Jun 2014 10:05:29 -0700 (PDT)
Received: by with SMTP id w8so1777047qac.24 for <>; Thu, 05 Jun 2014 10:05:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dCrNNOKTiFr08kWHXOeLGLomfHLweLBFY3i5M7YjM3E=; b=EU4hl9mqz+Rh4i1yXCYGY62ueykUMPotF6hxQcfHPK4mzuQm93BiqA7rAP4oaPfFLQ +jnXLMS36OA6QcuuGkwCLR13D+yvYr6MQTBUqdX8qm0hqIrE4OE/WE8R8lRoe2kHJ3Ba QwWrLrq4+x8qjBs4AXKO9a69Pg5iWhy/XGWBrdFc8r14LdVqZ0ecMtsO0ceYZ3lTHpdM eWBXnGm5SoPbMotUF5sKO2s2purSsnnEEiPB2++XNDN9IB9IcG2TrXZ7oAtlCAOzNYiO t2JGwjofjH4Zahq36nWq6ysBJp4U3Q9va4g0PwXUePb3IFojnEh3aV2hvd2btne4D6l+ jLYQ==
X-Gm-Message-State: ALoCoQn8ucor59wskM27YpdjmZOy1VyZFnGKrPQ0gs3rGRE2uOD83br886ItPxzz4V2mH4Wgk1NR
MIME-Version: 1.0
X-Received: by with SMTP id f6mr15591719qag.63.1401987922846; Thu, 05 Jun 2014 10:05:22 -0700 (PDT)
Received: by with HTTP; Thu, 5 Jun 2014 10:05:22 -0700 (PDT)
In-Reply-To: <>
References: <> <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <>
Date: Thu, 5 Jun 2014 10:05:22 -0700
Message-ID: <>
From: Brian Smith <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary=001a11c2d6d01efdbd04fb19c04c
Cc: Phillip Hallam-Baker <>, "<>" <>
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, 05 Jun 2014 17:05:45 -0000

On Thu, Jun 5, 2014 at 5:59 AM, Stephen Farrell <>

> I'll do an AD review in any case before I start IETF LC and will
> post a copy of that here. If other folks have comments I guess
> send those here or to PHB and me. I'd be happy to get a couple
> of mails saying "read it, its ready" after Phill's done his
> tweaks as well btw.

I read the document. I disagree with the documented semantics of the
extension when it appears in a CA certificate.

The specification says that when the extension appears in a CA certificate,
then the extension with the same values must also appear in all
certificates under that CA certificate. And, it says that a client may
ignore the extension in CA certificates. It would be safer if clients were
required to enforce the Must-Staple restriction if the extension appears in
any CA certificate in the chain. That way, the mechanism would work even
against an attacker that can issue themselves an end-entity certificate
that does not have the "must-staple" feature.

If this change were made, then the encoding of certificates as sent on the
wire would also become more efficient because fewer copies of the extension
would be needed: For example, in a chain EE <- Int1 <- Int2 <- Int3, where
Int3 contains the extension, the savings would be 3x the size of the
extension. Granted, the extension isn't large, but we should avoid such
waste since the size of certificates does have a significant impact on TLS
handshake performance.

IIRC, one previous version of the draft specified a mechanism for a CA
certificate to indicate that the OCSP response for the CA certificate must
also be stapled, using the OCSP multi-stapling mechanism. I think this is a
useful feature and we should bring this feature back. Otherwise, we'll have
to specify a new version of Must-Staple to support this later.

A more minor concern: It seems strange to have an X.509 extension, which is
identified by an OID, which is simply a list of unrelated features
identified by OID. In particular, why not just have a "Must-Staple" X.509
extension (or two: Must-Staple-End-Entity and Must-Staple-All) that is
(are) empty, and avoid the need for the "feature" wrapper extension? The
wrapper made more sense in earlier drafts because there was more than one
feature specified. Now, it doesn't seem to make sense. Removing the wrapper
would make the mechanism simpler and I think we should remove the wrapper.

Let's say a website's certificate's private key has been compromised and
that certificate was NOT Must-Staple. The website has no truly effective
mechanism to revoke that certificate, at least as far as browsers are
concerned. We saw how this played out (is playing out) with the Heartbleed
stuff. I think in the many years before Must-Staple could become
ubiquitous, we'll need another mechanism to indicate that all certificates
for a given hostname must be Must-Staple, whether they contain the
Must-Staple feature in the X.509 certificate or not. I don't know that that
has to be addressed in *this* draft or in a draft of a different feature,
but it seems like in the near term we should also have a mechanism that
applies to certificates that do not contain the feature.