Re: [TLS] OCSP must staple

Tom Ritter <> Sun, 08 June 2014 05:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A5C21A02D3 for <>; Sat, 7 Jun 2014 22:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ziu6NBnLSguX for <>; Sat, 7 Jun 2014 22:11:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EE551A02D4 for <>; Sat, 7 Jun 2014 22:11:15 -0700 (PDT)
Received: by with SMTP id jw12so2295063veb.39 for <>; Sat, 07 Jun 2014 22:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/Nye1xXJVwYTiUODSGHncv36/SdM3tKIucqy7fYK8ZA=; b=Y/NZ58qwr124HumBs8B9gNE62I58WGom5bDrvwihUIIPFLYifYBqipkuMVkx9RQY2/ KAk/HlY97mvmlBqYH+i7gISrq31LNXdSIkPbUBOGcIUUxqt1+vzHo3A0IcjonroT13HL pFhJY1WrsFssY7Gdnd7gNS7B81tXjajmkc++g=
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:from:date :message-id:subject:to:cc:content-type; bh=/Nye1xXJVwYTiUODSGHncv36/SdM3tKIucqy7fYK8ZA=; b=LauiyvzhmckNg+CBFFbIzRi6BR21hRRpeXLT4YYdPUUXI3M2RKZ88dMLxSXIgXHtDW wGDj8+7qEPqirOGAwtwcWD4YHLtlviSLOw7ioNwFuvXRDXoe3+dU65BVAa9IV3/q8CHA /Fc7fQ2f4cx0pWg3PmiyQhPBeonV0KpeAWCMSIwnQ0vX3fr96embV9nvuJY3f/dqR1zR TUbLTAEFlnJM33x6OqGIGkPPNZEIFa0cdxAtavC9XTCponuxImiL722TGjpYQPAC+wPF ipH0OVlE58FrUiOagQ34fGN7Lk7H2uHmhwB3UTGcZ/mwKlgWXLr1/PFaost4DYRaHXSV omFA==
X-Gm-Message-State: ALoCoQmo2TCJxWQ31a7l8j/uzysXNkLanDsSN6fSUpHKvuZePFTExOCS5Hhgu6i5ZKqd2cOGNUDR
X-Received: by with SMTP id y8mr17185648vci.21.1402204267467; Sat, 07 Jun 2014 22:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 7 Jun 2014 22:10:47 -0700 (PDT)
In-Reply-To: <>
References: <097101cf7aa7$17f960a0$47ec21e0$> <> <> <> <> <> <> <> <> <> <> <> <155f01cf82ce$7cfa8360$76ef8a20$> <>
From: Tom Ritter <>
Date: Sun, 8 Jun 2014 01:10:47 -0400
Message-ID: <>
To: Yoav Nir <>
Content-Type: multipart/alternative; boundary=047d7b3a925043ed1c04fb4c1f51
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: Sun, 08 Jun 2014 05:11:17 -0000

On 8 June 2014 00:59, Yoav Nir <> wrote:

> dictate to whom?  Isn't the presence of this extension a mandate on the
> server operators themselves?

Well, yes, but in the same way that HSTS is a mandate on a server operator
to make their site available over HTTPS.  I think the mandate is more
accurately terms as for the client.  If a staple is not provided, you
should reject the certificate as invalid.

> And enforced how?  Suppose a server sends the client a certificate with
> the extension, and does not staple an OCSP response, are clients going to
> cut the connection or are they going to try the OCSP server. And if they
> try the OCSP server, is ti going to reject them?

While it looks some of the semantics of 'Must Staple', I think either
behavior could be acceptable for a client.  Either closing the connection
without attempting to contact a OCSP server, or switching to a 'Hard Fail'
OCSP lookup.

I can imagine some servers deciding that they would want clients to fail if
they didn't send a staple, rather than leak the OCSP lookup to the CA.  I
could imagine other servers wanting to hedge their bets and have the client
make an attempt before giving up.

I don't understand what you mean by the OCSP server rejcting them.

> I'm trying to get my head around how this extension is going to be
> deployed.

I see it as a server opting in to strict revocation checking for a
certificate.  (Later on, for the host itself, but for now, just the