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

Ryan Sleevi <> Sun, 09 May 2021 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49FEB3A221B for <>; Sun, 9 May 2021 15:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.498
X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3YBqXIxYJIVg for <>; Sun, 9 May 2021 15:20: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 7208E3A221D for <>; Sun, 9 May 2021 15:20:59 -0700 (PDT)
Received: by with SMTP id m124so11901797pgm.13 for <>; Sun, 09 May 2021 15:20: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=elCVoMUNQwW6OI28yttPUcZCP29nr4Tg8WtYe7I3940=; b=ZzmVvaaAb3bN75+JJtUuuvNU8jNQC4VzZvpiM7eR783tvQ+KKQJ9E9bOaiFE7FZ3Ov sBV48NEq7KFwykAXjGJfzFjbIGwPfB5shCEF0/JWL32remcfQFnt29fDDcTBGha0kuAM GJKTzPOMqtgWG9XuulIwHP9SBxm5/q2D4Z7dNL8z6P6wCFEZj03S5w3F7dfg/YwwTjNc HiU14J0o4399SMMSH82vKNShq7CJceBbEduQtTVNtzIjzux1rDHOv/sOo+zMGIVw4Dfr agbeWnRZTDjUL9Qt+j9e7VImtaMw8MgPYgqCOfjuw8IEaDmvrgdY/xVEYyTSdxXdBWbi 0j/A==
X-Gm-Message-State: AOAM530F7eFguZEKQzB4tB6k1BZQiz8LN34LI5O/vt6C2kPN4jDcTGzD 90TA7bLmm5qOnbnFQjHGtnA52FX3zug=
X-Google-Smtp-Source: ABdhPJzyOkn/bfsoqHfcSQSStox+KH82KQ38OXbP9tPB1+si2/+UTgqIpHLbpRpibnQt2Xw6Q9ku4Q==
X-Received: by 2002:a62:1c0f:0:b029:25f:ba3c:9cc0 with SMTP id c15-20020a621c0f0000b029025fba3c9cc0mr21428274pfc.56.1620598858136; Sun, 09 May 2021 15:20:58 -0700 (PDT)
Received: from ( []) by with ESMTPSA id b3sm1972934pfv.61.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 15:20:57 -0700 (PDT)
Received: by with SMTP id fa21-20020a17090af0d5b0290157eb6b590fso9158490pjb.5 for <>; Sun, 09 May 2021 15:20:57 -0700 (PDT)
X-Received: by 2002:a17:90b:4d08:: with SMTP id mw8mr37117556pjb.202.1620598857630; Sun, 09 May 2021 15:20:57 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Sun, 09 May 2021 18:20:47 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Mohit Sahni <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000003b8ad905c1ed1332"
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: Sun, 09 May 2021 22:21:02 -0000

On Sun, May 9, 2021 at 1:14 PM Mohit Sahni <> wrote:

> Hello TLS WG,
> RFC6962 only talks about support of CT to verify the server
> certificates, however while working on zero trust services that
> require MTLS for each connection, I realized that enabling CT for
> client certificates can make the TLS handshakes with Mutual TLS more
> secure. (I don't want to go into details of how CT can make it more
> secure as those benefits are already mentioned in RFC6962).

Question: Are you assuming existing Certificate Transparency logs (i.e. for
Web PKI), or are you standing up custom logs?

I'm not aware of any client implementations that allow custom logs, so I
think it's reasonable to take implicit that you're discussing Web PKI, in
which case, using MTLS like this unquestionably is *less* secure and
actively harmful to security, due to the significant fragility in mTLS
(e.g. a lack of automation on the client side, a lack of robust
verification on a server side). This is why, for example, there have been
discussions about forbidding serverAuth certificates from the Web PKI being
used for clientAuth, due to the associated harms.

Assuming you are discussing a private PKI, then I would say the
justifications of 6962 are things you can address early on with the PKI
design (i.e. avoiding the multi-party PKI that the Web PKI has). So it
should not be taken for granted that CT is the "right" solution.

However, going further, and if we assume a private PKI, with a
multi-stakeholder scenario that makes 6962 useful for your case (i.e.
implying the PKI design is already problematic), then there's not a way for
the server to indicate its expectations of the client's certificate being
logged, and this is arguably a feature, not a bug, since "being logged" is
a nonsensical phrase without understanding the server's set of logs.
Indeed, the "right" way to do this is to follow the same priority
preferences that exist for server certificates, namely:

1) Ideally, embedded within the (client) certificate itself
2) If not embedded, then included as part of the TLS handshake (which TLS
1.3 makes it possible for clients to send such information, and surely no
one would be building new mTLS on TLS 1.2 given the issues with client
certs in 1.2)
3) Optionally, embedded in the OCSP response, although virtually no client
mTLS implementation supports OCSP stapling correctly, which is also a TLS
1.3 thing

However, again, going back to first principles: If your goal is to
repurpose existing PKIs, such as Web PKI, for client certificates, then
that's fundamentally flawed on many levels, and has the risk of creating
both operational issues for you and your clients, and in doing so, creating
security issues for the broader ecosystem of users relying on the Web PKI
for servers. If your goal is to establish a new PKI for such purposes, then
there are plenty of approaches early on in the design that can avoid the
set of considerations that directly lead to CT, and while there's still an
indirect benefit, it may be that you find the simplicity of a secure,
private PKI avoids the need entirely.