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

Melinda Shore <> Sun, 09 May 2021 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 253DD3A2042 for <>; Sun, 9 May 2021 14:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 DnVoiMf83riJ for <>; Sun, 9 May 2021 14:22:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61C783A2040 for <>; Sun, 9 May 2021 14:22:25 -0700 (PDT)
Received: by with SMTP id z6-20020a17090a1706b0290155e8a752d8so8902339pjd.4 for <>; Sun, 09 May 2021 14:22:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=l4r98sBNGGuCt0cmkYBOYYHabfX95a1w5kQsd3MTlvg=; b=lMIDxKyOm6rcYa0mbgmp9pfSESRrUf6rBa3LOwTp9TXQmMwwuPMA5AwbtZkNoLee6M bsnjjkYeQaDbnp580H78ltzUk2kLzTKo9hauBpn7W9y4UZ9Mz2mmN+VDEdfSd9MjCwMV vuCdW9WC2XsM5MywW5KHfEJSVGOZ49HtZ51coSXQn5Uc4vKvJCPG1dPKwYOw6B0J4fmE V1+Zuhl+XzY2V2c3onopMP1e9+o8Q8qonC1RGfwKJmjYcPpkKdkS0pdXl0uHwzsqlndo 8zWOfF1MeTj3xcjFpoiVoGr2PI7SmUn+PYb1+z5TcgXZjy/7wk9tClZNB6n+1z5wLitl tD0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=l4r98sBNGGuCt0cmkYBOYYHabfX95a1w5kQsd3MTlvg=; b=fOIcXXTXTRVOnYYsN2VUqXzbrAnP/2JmQu+P/L4CAYfEjlLr4Vn3AUtuwQxwRJkC7z EN4J1Q2tGNpsqmTPqBq6YCoT4rAa2O9zOISMqx4uEqHTxWfnCfKecEX7nwgZbhs8n+ru 3zwSoVZVfN4ls9LHTSZqqb65aRM0CdkH1phJzZcPYzik3tl95NYA0tGm8GPEOVdMk7Ir vIdvbeT6YA0kTKCTvMrTVlDSj8jXZCKTburhZFnEmQcW/aJsaCZIAJbOY6r5X21pDfXT cwRvfoUv+YlfG6HLeEswwUMVEdm6Aw7dx/HWWqJQUvQUuZ6+0oxpbdhUiDaY/4qj6uMX 2u8Q==
X-Gm-Message-State: AOAM530bwHgpgXOhf/B2PKRCqczBfFphFgwr8yAGGFvu0LBpE3GMC4/H V5XgJSL9nl58vdy1kgX89/ePLD+0Jmef
X-Google-Smtp-Source: ABdhPJyG6RplsPtwY+k+EeeM64JRvz1Ja7dlAtz9u2HygOOqTlwVzyogkBItfDi87bCfMAxy+pdWyg==
X-Received: by 2002:a17:90a:3847:: with SMTP id l7mr36349791pjf.37.1620595343833; Sun, 09 May 2021 14:22:23 -0700 (PDT)
Received: from aspen-2.local ([]) by with ESMTPSA id n18sm9370299pgj.71.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 14:22:23 -0700 (PDT)
References: <>
From: Melinda Shore <>
Message-ID: <>
Date: Sun, 09 May 2021 13:22:20 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 21:22:30 -0000

On 5/9/21 9:13 AM, Mohit Sahni wrote:> 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).
Both approaches seem reasonable/obvious, although the OCSP-based
one seems to have a few potential issues (both around stapling and
around spotty implementation of the use of OCSP for client cert status
checking).  But I have to say, the core problem this proposal
faces would seem to be lack of demand on the part of folks who
consume client certificates.  In the seven years that trans has
been up and running this has received nearly no discussion, even
in passing, and if I recall correctly, no drafts and no agenda
time in meetings.


Melinda Shore

Software longa, hardware brevis