Re: [pkix] Two way OCSP Stapling and Configuring Windows responder URLs w/o AIA presence

Russ Housley <housley@vigilsec.com> Tue, 21 June 2016 21:26 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B13812DE1D for <pkix@ietfa.amsl.com>; Tue, 21 Jun 2016 14:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKGdkOPFcpsL for <pkix@ietfa.amsl.com>; Tue, 21 Jun 2016 14:26:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7F112DE1C for <pkix@ietf.org>; Tue, 21 Jun 2016 14:26:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 344373002BA for <pkix@ietf.org>; Tue, 21 Jun 2016 17:26:43 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xq9BG1rnMm_k for <pkix@ietf.org>; Tue, 21 Jun 2016 17:26:41 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 641103002A3; Tue, 21 Jun 2016 17:26:41 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC6633B9-4F2E-4C0D-B6F3-8C5A564E3724"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CAJKvcBSV8rbVOyXJA0j-jTsA2tvg==yz9Gfns3SU6ZYUG=+dbQ@mail.gmail.com>
Date: Tue, 21 Jun 2016 17:26:34 -0400
Message-Id: <83CCA806-CD84-4387-967F-E797EF216E71@vigilsec.com>
References: <CAJKvcBSV8rbVOyXJA0j-jTsA2tvg==yz9Gfns3SU6ZYUG=+dbQ@mail.gmail.com>
To: daniel bryan <danbryan80@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/dVgGgdQe2JtHDJugpZxgkMpKEs8>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Two way OCSP Stapling and Configuring Windows responder URLs w/o AIA presence
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2016 21:26:47 -0000

Online Certificate Status Protocol (OCSP) is specified in RFC 6960.

The TLS Certificate Status Request extension is defined in Section 8 of RFC 6066, which says:

   Servers that receive a client hello containing the "status_request"
   extension MAY return a suitable certificate status response to the
   client along with their certificate.  If OCSP is requested, they
   SHOULD use the information contained in the extension when selecting
   an OCSP responder and SHOULD include request_extensions in the OCSP
   request.

and

   Note in addition that a server MUST NOT send the "CertificateStatus"
   message unless it received a "status_request" extension in the client
   hello message and sent a "status_request" extension in the server
   hello message.

I do not see anything about the client providing an OCSP response for their own certificate.

Russ


On Jun 21, 2016, at 9:11 AM, daniel bryan <danbryan80@gmail.com> wrote:

> I believe i understand the concept of OCSP stapling in regards to a webserver presenting it's own certificate status to the browser client in the TLS handshake. I am curious if a client (personal certificate with digital signature key usage) authenticating to a webserver with their certificate can also present it's own certificate status so the webserver doesn't have to determine the status from an OCSP service. 
> 
> 1.) Does the standard allow for this? I believe it does since the verbage says "It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS Handshake"
> 
> 2.) How is this configured in client browsers, are 3rd party addons required?
> 
> Vaguely related, but i remember their being a dependency on windows ability to provide a stapled response via IIS. It required the presence of an OCSP url in the webservers AIA field. I would like to overwrite/hardcode the URL, like you can do in (certmgr.msc) certificate properties adding a responder URL. Sort of like doing a "SSLStaplingForceURL uri" directive in apache.  I posted this question on the iss forums about this, but was not able to get a resolution. http://forums.iis.net/t/1221792.aspx?OCSP+STAPLING+ForceURL+Option
> 
> 
> 1.) Is it possible to configure windows to use a specific responder url for providing stapled responses when an ocsp url is not present in the AIA of the servers certificate?
> 
> 
> 
> 
> Thanks,
> 
> Dan