Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni <> Mon, 10 May 2021 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A30CE3A282C for <>; Mon, 10 May 2021 12:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IkdNKvWurdGZ for <>; Mon, 10 May 2021 12:23:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C15D3A282B for <>; Mon, 10 May 2021 12:23:19 -0700 (PDT)
Received: by with SMTP id i7so8402219ioa.12 for <>; Mon, 10 May 2021 12:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uLu+n/ifw/9UOt2AAc0vsmtyFvMLdIbe5vjTaLLe+jM=; b=l0AXRhYQ9zw56WdW6x7VGOYw2PcMFA0/rHNAVJ9roM6EYG/8XiUm6muhS6UQ/Bll7M l8ycNcsF2gRyCo0rWDaml/8O2QC7ZS8ZvMo3ZxiDRgRXy9se1rpoUMRMWZscGGUSa1jO NngvhBrT8qHCfD+dUoZ+qaFeZZTlcjSR71Q5wR7wDSANmPJV/5wQSdX3xb7m8iktXPwx c1BSnkBuRrXrTNpTvMK8BeJRqhlzLRlUL3IprpGB7FWywIVvgZDoymAwPDmOsNTNFHeU BYWVzSQP0eQs9mMAdaMOOTbiM3NKPfya+knog+XXIXuhtsk1tCZu+y/cbXgGMNbJt/qV Ai3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uLu+n/ifw/9UOt2AAc0vsmtyFvMLdIbe5vjTaLLe+jM=; b=ovQL6x7FcgbFNkdwFwduDRUJk9/bQGERuVnaLDf9O4csCVUcwF5bvF/QGBQ4mpIXFU E3sJLgINzWvC/417X2UdrLDSJd4FN4o80FAc86GGtaLf6VCkTgjUK43ABV1TjXR0/je7 R9WVk3pKCc2K/9SCSZKEH3iLzaX1RSJCIPS2utNEtEwz+2cp5ZnUWpLwK9rSgFR9NJ2V +mqxnAJq67FTPpGClqcy/5jrIZnzO12zn5+2jJ9UpmLL3d6wNfnpvrgklyXz+j3QX5Ap q2i937Xy35+LV92flCgfL17fYIuyLCL4pWH6u7j/QddOVNb8lx2pMT9QrGCe3gRa18fi TYzg==
X-Gm-Message-State: AOAM5315AgLvhjrm91tA4ZHtgiuI12kylq4KbYuwYXYKSr0gweogce3k XQLK29y6b2+tQs/oF1gcG/5Rd/JdTpGWtCBe2H4=
X-Google-Smtp-Source: ABdhPJy2nPrrehjtr3jTL62B2KbLKvg3t9nr/2CYby1WcPH9akKa3Za1KASdwEBImvdPS4M7KSMJ91i4rGSwj2WOz8s=
X-Received: by 2002:a5d:9ada:: with SMTP id x26mr18893851ion.209.1620674597174; Mon, 10 May 2021 12:23:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mohit Sahni <>
Date: Mon, 10 May 2021 12:23:06 -0700
Message-ID: <>
To: Ryan Sleevi <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
X-Mailman-Version: 2.1.29
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: Mon, 10 May 2021 19:23:29 -0000

On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <> wrote:
> On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <> wrote:
>> Hi Ryan,
>> Thanks for answering my question in a lot of detail. I asked this
>> question in the context of a private PKI for client certificates. You
>> can assume a scenario where the client certificates are issued to
>> users/devices in an organization from a self service portal by the
>> organization's existing private PKI for 1000s of users under different
>> domains (multiple CAs).
>> What I get from your answer is that using CT for client certificates
>> makes sense when:
>> 1) There is an existing private PKI.
>> 2) There are multiple CAs issuing the client certificates.
>> 3) The PKI uses non Web PKI (non public) CT log servers and auditors.
>> I don't agree with your comment about following the same priority
>> preferences that exist for server certificates, the [2] and [3] makes
>> more sense when reversed or kept at an equal priority in the context
>> of client certificates. Here is my reasoning:
>> In the server PKI, it is practically easier to make changes in the web
>> servers to support [2]  (i.e. sending the SCT extension by pre
>> fetching the data from the CA) but it may not be that easier to
>> implement it on 100s of thousands of client devices. Imagine a large
>> cell phone manufacturer implementing [2] for all the devices that they
>> have sold in the last 10 years.
> Right, I can understand the temptation to consider OCSP Stapling as a more attractive solution, because it relies on the CA taking the requisite action, and thus avoids the need for client implementation, in theory. But the problem is that it's largely "in theory" - that is, robust OCSP stapling is just as hard for clients to implement as obtaining SCTs directly.
> Nearly 6 years ago, I wrote up [1] to discuss what robust OCSP stapling looks like, from the server side, which captures some of the challenges here. Few servers robustly support this (I believe Microsoft IIS and the Caddy web server are the two notable exceptions), and so the idea of pushing that all to clients is roughly the same challenge as having clients obtain SCTs directly. The main argument for OCSP-embedding over TLS-embedding is not one of simplicity, but of centralized control and communication: the idea being that you can have all your clients contact a single point of contact (the CA's OCSP responder) to obtain the policy.
> For servers, in the context of the Web PKI, it's quite appealing to swap priority for OCSP-embedding over TLS-embedding because of this. It equally gives Web PKI CT Logs a single point of contact for purposes like rate limiting and abuse detection, which can make it easier to address any concerns. However, in the threat model of "Unreliable CA", where CAs continue to fail to implement CT correctly [2][3], that seems to be missing the operational lessons. Given the assumption that the model here was private PKI with private CT logs, then you're likely better off with a (privately expressed) policy mechanism on the client versus trying to robustly support OCSP stapling on clients, since the failure mode here impacts not only CT, but the revocation processing.
> [1]
> [2]
> [3]

I think you misunderstood me, I am not recommending the use of OCSP
stapling here. I agree with you that the OCSP Stapling is practically
almost the same as a client fetching the SCT and sending it to the
server in the TLS stream. I am recommending that the CA/OCSP responder
can attach SCTs as an OCSP extension along with the revocation status
of the client certificate in the response to the server's OCSP Request
and server can verify the certificate based both revocation status and
the number of SCTs in the OCSP response from the CA/OCSP Responder. I
know there are issues with how OCSP is implemented by various vendors
but we can always work on learning from the mistakes and improve OCSP
to make it more interoperable.