[TLS] Certificate Transparency for Client certificate in MTLS handshake

Mohit Sahni <mohit06jan@gmail.com> Sun, 09 May 2021 17:13 UTC

Return-Path: <mohit06jan@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2C6863A164C for <tls@ietfa.amsl.com>; Sun, 9 May 2021 10:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CkGIh2vqbALY for <tls@ietfa.amsl.com>; Sun, 9 May 2021 10:13:54 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70233A164B for <tls@ietf.org>; Sun, 9 May 2021 10:13:54 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id l19so12034552ilk.13 for <tls@ietf.org>; Sun, 09 May 2021 10:13:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MRKw6DluKf8lpWpmWRik/xSxYU8a77yDfEUYR5z3QiY=; b=Ev41aFaKnCAN/vHdloNfoq7IA+6rezSKRgR+gxOyPPx0jq46+lrkSEefqegxObsxr9 ojD2TAD9CS027ssKAUYhuoGZqT5dKBW1Gr02zrvvwv8b9HVG7CmL1L1/rcJdYD9Xvfyk NMIX2vwYQvSQPhlpetHk0n29kvbniSC0e8VWkDAO3vxErXFBxa1gXykAsddzV9RsPK+4 6XSxJ8ve/1JYAtPOmDHeQlN2FACajo3xHP865m9UKjzFCwXET4eF8B32tKpmTWonG82u zo6NJFvcsn/HeNfyWWITySKZ9WMvIfo15ldPmNOTyMR//eXpkXl7OvjBpOK6ukRrVgig soQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MRKw6DluKf8lpWpmWRik/xSxYU8a77yDfEUYR5z3QiY=; b=LLHiWP02oYJRIok1nxlOOoUu2zMnR/v5dKgVFGMmKrJQC05jnLhW4dvVf6jHPnnky1 EbWIY0Cbs6KhAHk5pSqshd/BlGpYWYisVclj3BysqQr7IFu65h0NqUsJdava1G7QGWOV UoCnnNvjjueLIay/xwqjGA68w6bZbeYv9OGLSm2NFIkvz+o0C2UQcw+9KL+nmcQmZrKx MYPV5bFdnzAOfOmdtpy+CbIWG4bRWLervua7M5yDr7kbvf+Lg8T/yr3n2IbK6LhSB2bG 5XHRwf3Pe0zqaZ0sKVmu6ormGOqkr8GGylN6vIo+gjBuziprGs58JoNLE2wh3s418g+8 DjCQ==
X-Gm-Message-State: AOAM530Yv4vdbIKLd9Ticg06CLXO/vjHVZvqeFdOut1WHUioJdRZzdxC ovJqulGsi5iYD3bMB34zig4A7UjpS2rdbOGaz8wkPleR5Zx5zg==
X-Google-Smtp-Source: ABdhPJyGk5/wuc0bgTfMXo+UgvLf+K+zCY7dSPqLPsgxtcHSfM+B4x5L1SMesAEF7lrnBKQe0YCY+6YNio8uG5PGoNw=
X-Received: by 2002:a92:7609:: with SMTP id r9mr18836239ilc.297.1620580432955; Sun, 09 May 2021 10:13:52 -0700 (PDT)
MIME-Version: 1.0
From: Mohit Sahni <mohit06jan@gmail.com>
Date: Sun, 09 May 2021 10:13:42 -0700
Message-ID: <CAEpwuw2tBLn-7b1YBXf3YfS4WXM-JrKbfHsQPt=_H4FYKYdmVQ@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/X0OIz9u8emrFdjtzESWmiIwDnC0>
Subject: [TLS] Certificate Transparency for Client certificate in MTLS handshake
X-BeenThere: tls@ietf.org
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." <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: Sun, 09 May 2021 17:13:57 -0000

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).

Here is how I think it can be supported and I am looking for your
feedback on this.

Approach 1:
If a client has sent the signed_certificate_timestamp [RFC6962] in the
client hello with empty data and if the server is configured to only
accept the client certificates with a CT log, server will send the
signed_certificate_timestamp extension with empty extension_data  in
the Certificate Request [RFC 8446 section 4.3.2] message to indicate
that it requires certificate's Signature Timestamp as a proof that the
certificate is logged with a CT server.

On the client side, If it's certificate does not have an SCT
extension, then the client can either be configured with a static SCT
data or it can be configured to fetch it from an external server. The
client can use the SCT data to add a signed_certificate_timestamp
extension in the CertificateEntry in the Certificate message [RFC8446
Section 4.4.2 along with its certificate.

Approach 2:
Another way could be the CA of the client's certificate can send the
signed_certificate_timestamp extension in the OCSP response to the
server indicating that client has a CT log along with the log. Server
can enforce both CT and Revocation checks at the same time.

Please let me know your opinion on this and do you think there is some
merit to standardize this. Thanks for paying attention to my email.

Mohit Sahni