Re: [TLS] Client programs and stapling?

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 21 May 2022 15:19 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6172CC15E6E7 for <tls@ietfa.amsl.com>; Sat, 21 May 2022 08:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQYRJAudh7Ty for <tls@ietfa.amsl.com>; Sat, 21 May 2022 08:19:30 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC9FC14F607 for <tls@ietf.org>; Sat, 21 May 2022 08:19:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 02635680C6 for <tls@ietf.org>; Sat, 21 May 2022 18:19:26 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id V7t3ceYOzdrv for <tls@ietf.org>; Sat, 21 May 2022 18:19:25 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A0BC82A0 for <tls@ietf.org>; Sat, 21 May 2022 18:19:24 +0300 (EEST)
Date: Sat, 21 May 2022 18:19:24 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <YokC/JfQW98JVy5I@LK-Perkele-VII2.locald>
References: <EF0C1982-52C3-4CFB-A51F-65FE905B79E0@akamai.com> <CAF8qwaBB4Buf7anJ1t9onem1K7fCvcR1e18zHUVa7GqxRjNr1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAF8qwaBB4Buf7anJ1t9onem1K7fCvcR1e18zHUVa7GqxRjNr1Q@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VsmS08SPhDp-YzsATEsxmy1_uzI>
Subject: Re: [TLS] Client programs and stapling?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 May 2022 15:19:32 -0000

On Fri, May 20, 2022 at 01:23:31PM -0400, David Benjamin wrote:
> On Fri, May 20, 2022 at 1:07 PM Salz, Rich <rsalz@akamai.com> wrote:
> 
> > Do client programs staple a status when sending a cert to the server? It
> > seems possible, someone just asked me if anyone does it.
> >
> Prior to TLS 1.3, it wasn't possible because the Certificate message
> didn't have extensions. Starting TLS 1.3, it looks like we did define
> status_request to be allowed in either direction. We (BoringSSL)
> never implemented the client certificate direction, since we haven't
> needed it yet. We just ignore the extension if we see it in
> CertificateRequest. At a glance, it looks like OpenSSL does the same.
> Dunno about other implementations.

Looking at what my implementation does, if an application gives the
library an OCSP staple to send, it will be sent if server requests one.
However, I do not think any application using the library does that, so
in practice OCSP never gets stapled into client certificate.

(Similar thing appliles to Signed Certificate Timestamp (Certificate
Transparency) stapling, and in some very recent versions, Transparency
Item (Certificate Transparency 2.0) stapling.)



-Ilari