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

Avamander <avamander@gmail.com> Mon, 10 May 2021 13:55 UTC

Return-Path: <avamander@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6728C3A1D9B; Mon, 10 May 2021 06:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygEI_zdEX2yr; Mon, 10 May 2021 06:55:45 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 0A7AF3A1D9A; Mon, 10 May 2021 06:55:44 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id h202so21706952ybg.11; Mon, 10 May 2021 06:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dVVtQAKLtf/D6DfFT9lOmJ6UotBkrIGUqPPQpoIxitI=; b=f/kvEkK+LBjWNG3ZhOVowOZyEWj3aI0R5VPGDv08XIXgQzwCUsukFfeRdL5AbgGN9Y ErpnUNAxKCH4SMWrAyTKfT4+4t5DJXKwjo1l9Orol9l+y9LxpPl7+Tadg5iCxZhAx9Lz K1My2FUXzJx8cwKNUYXTFJg0sQJxn5VzTLYC8k0W3Ic8b8yp2Z8X6R54I4ywWSkuKr22 ltBSnnWA0LOz+kddbr1ovdlL5iISRyp7Z8VlbsG7V5EIBUIurS4D5xcoecehAvx85ZZ+ vSXigJEGWH0xVeOiCZmxcDoTj8xo5DbmQKbMOfyEOyInMStN1v/vGlvtSxwjZMge1/Sm +S4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dVVtQAKLtf/D6DfFT9lOmJ6UotBkrIGUqPPQpoIxitI=; b=Bv1Fn14A6qmZtqbO1+gKiwL9j7Xuu+MmOBFsOLOIZvtNh/63q7LAZzJac8WM8JvgiU zWtN6pmND46aCr+XL92Q6KaJZWHO9fVRphOm8Cwi2tDU/RYuON2iWLQicy4RoKeWLjut jybNe5jcayYIqXaMFmgMdgO0myUrFhtY57vxrNnaifms5l0f3kDpf67vo9otyLfUR9DH gvi/FFiGPF9D1kfMg5RNa5+Lr32Row6fyk8IRRHpNAn42vNFmJVRCbKefHgT5u2Aga/F dguQ/h/zBpvybONLAlBuJUbIVh0Mmq0AXmKM2Jt/tyGNChBXZ/oI/gZkk+hlqSKHOYgn n5iQ==
X-Gm-Message-State: AOAM530YYoV0+K024Vgm+hchFhS0aVosRG+m9UEZNVhgKOMjd23mFK5P Id6OG5zEaJn5QzzeH9ha3bCTRvPW7iIEw8ey/4/Aw1UbqRY=
X-Google-Smtp-Source: ABdhPJw+UgzdTWCDmuPciselfOcolZHI5vvhvBnM3SUWug2f+GqkxxuIsQfxZTnwhIah/0/6Jb9zqoQn2eLp+YhPmxE=
X-Received: by 2002:a25:ae09:: with SMTP id a9mr32037531ybj.76.1620654943450; Mon, 10 May 2021 06:55:43 -0700 (PDT)
MIME-Version: 1.0
References: <CAEpwuw2tBLn-7b1YBXf3YfS4WXM-JrKbfHsQPt=_H4FYKYdmVQ@mail.gmail.com> <7d9d6d72-2471-e983-ffef-71c5a706abeb@nomountain.net> <DD1EE792-A70A-4DD9-BFC5-2BD011F6F29D@akamai.com>
In-Reply-To: <DD1EE792-A70A-4DD9-BFC5-2BD011F6F29D@akamai.com>
From: Avamander <avamander@gmail.com>
Date: Mon, 10 May 2021 16:55:32 +0300
Message-ID: <CAPLrxsEpj-qwVS55APR0wNOE+3aPzdZyJYonee_daZAd_=TwvA@mail.gmail.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Melinda Shore <melinda.shore@nomountain.net>, "tls@ietf.org" <tls@ietf.org>, "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003540ef05c1fa2298"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gMU8CwbV54mPfFI9fFpJaOq6f6M>
X-Mailman-Approved-At: Mon, 10 May 2021 08:24:52 -0700
Subject: Re: [TLS] [Trans] 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: Mon, 10 May 2021 14:02:37 -0000

> faces would seem to be lack of demand on the part of folks who consume
client certificates.
> I'm not aware of any of our customers (the few that use client certs) who
also use a public CA, or even more than one.

With the relatively slow adoption of the EU's eIDAS legislation and thus
national PKIs, the demand will probably grow, but within a decade. But it's
unlikely that countries themselves will show any interest in participating
in this process because the adoption of CT itself is far away.

My humble prediction is that in a decade people will finally start using CT
in the context of MTLS and find it somehow broken, that is if it's not
taken into account right now.

On Mon, May 10, 2021 at 4:04 PM Salz, Rich <rsalz=
40akamai.com@dmarc.ietf.org> wrote:

> >  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.
>
> Agreed.  In our experience, client certs are deployed from an enterprise
> PKI, and the receiving consumers assume valid issuance. I'm not aware of
> any of our customers (the few that use client certs) who also use a public
> CA, or even more than one.
>
> Added the trans list.
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>