Re: [TLS] OCSP must staple

Rob Stradling <> Fri, 13 June 2014 10:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A8471B27FF for <>; Fri, 13 Jun 2014 03:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zgyPivHVuaQs for <>; Fri, 13 Jun 2014 03:32:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACC521A854B for <>; Fri, 13 Jun 2014 03:32:36 -0700 (PDT)
Received: (qmail 3251 invoked by uid 1000); 13 Jun 2014 10:32:34 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 13 Jun 2014 11:32:34 +0100
Message-ID: <>
Date: Fri, 13 Jun 2014 11:32:34 +0100
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian Smith <>, Yoav Nir <>
References: <> <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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: Fri, 13 Jun 2014 10:32:40 -0000

On 12/06/14 19:21, Brian Smith wrote:
> On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir wrote:
>     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.
> Thanks for sharing that information. Does your product copy all the
> certificate policies from the original certificate into the forged
> certificate? If your product doesn't copy certificate policies it
> doesn't understand, then there wouldn't be an interop issue with your
> product and the use of certificate policies for Must-Staple, even if
> your product doesn't generate short-lived certificates.

So far we've been discussing two options for how to encode the Must 
Staple indicator:
   - As a new Certificate Extension.
   - As a Certificate Policy.

Here's a third option...
   - Put it in the Authority Information Access extension.

RFC5280 says that the AIA extension...
   "indicates how to access information and services...(which) may
    include on-line validation services and CA policy data."

The AIA extension's id-ad-ocsp "accessMethod" specifies "how to access" 
the origin OCSP Responder directly.  Now, compare id-ad-ocsp to OCSP 
Stapling and Must Staple...
   - "information and services": identical.  For all three, what we want 
is an OCSP Response.
   - "how to access":
     id-ad-ocsp: SHOULD get the OCSP Response from the OCSP Responder.
     OCSP Stapling: SHOULD get the OCSP Response from the TLS handshake.
     Must Staple: MUST get the OCSP Response from the TLS handshake.

We could...
1. Use the existing id-ad-ocsp "accessMethod", and define a new 
"accessLocation" that uses a type other than a 
GeneralName->uniformResourceIdentifier and has the meaning "the location 
is the CertificateStatus TLS extension sent by the Server".
2. Define a new "accessMethod" that has that meaning.  (Not sure what 
we'd put in the "accessLocation" though).

Would this approach be any more or less likely to work with proxies?

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online