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

Ryan Sleevi <> Mon, 10 May 2021 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41E4D3A1C69 for <>; Mon, 10 May 2021 08:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MevWIYuGqH7u for <>; Mon, 10 May 2021 08:41:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76D293A1A48 for <>; Mon, 10 May 2021 08:41:59 -0700 (PDT)
Received: by with SMTP id gq14-20020a17090b104eb029015be008ab0fso10293460pjb.1 for <>; Mon, 10 May 2021 08:41:59 -0700 (PDT)
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; bh=ERVz+FmsHOCO9zB/8KIQOQEsDLJJm4jYK1BBLrRy4hc=; b=fKL4oFFoR+w8wpTDihnTJtJV4n4jA83cxECKRFQPQcBU4FZaViZI7k2bBjizK8i8s9 oZku85lAflsrMZz0VCC1XqIWLmUjlbz7l2aq6O+Z0Pr36iIvHGK9matloJgZfmUM7+ui XJAZCE+ZQ9kOhrJCUocBEx3x13XDXkxit6pNWVXHFjse+VV8lN7dj63wTKEQhZTO7saZ Btfw29jYQ8Rg9X0Y5XCPmTSHq0QiFfNM0CbdCm2b/7eNIfXHI0bT+86EpdBULGwtMd7D 1cgJ1scfnATIkTuE0CRk5KvhEfqQvYxJPppoNKtaoyn6wl2jOO9txQ5zJy0xCWgG1Ox+ re+Q==
X-Gm-Message-State: AOAM532wzp9+hewQoLFL7/R1yXQ4YWlq7Rl5W6WRtd2xDo6TTPNyd/IY 6MIbHqn8utooHXFCvVXCONt87V0qDRU=
X-Google-Smtp-Source: ABdhPJw3qdmjp9n3AKHo+DNGLXHbzPFjO+yG7iFIs3ety5Or/QuLTCiEM4y1keVug+cn/g3WXJrbTw==
X-Received: by 2002:a17:902:b616:b029:ee:c73b:163d with SMTP id b22-20020a170902b616b02900eec73b163dmr25489370pls.30.1620661318710; Mon, 10 May 2021 08:41:58 -0700 (PDT)
Received: from ( []) by with ESMTPSA id s8sm11340701pfe.112.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 08:41:58 -0700 (PDT)
Received: by with SMTP id g24so9998244pji.4 for <>; Mon, 10 May 2021 08:41:58 -0700 (PDT)
X-Received: by 2002:a17:90b:4d08:: with SMTP id mw8mr41530429pjb.202.1620661318238; Mon, 10 May 2021 08:41:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Mon, 10 May 2021 11:41:47 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Mohit Sahni <>
Cc: Ryan Sleevi <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000002cc7f805c1fb9e4a"
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 15:42:04 -0000

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

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.