IETF Logo Mail Archive

[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 19 June 2025 07:52 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B777F36D2C4C for <tls@mail2.ietf.org>; Thu, 19 Jun 2025 00:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1LGaPkgZ8Y3 for <tls@mail2.ietf.org>; Thu, 19 Jun 2025 00:52:37 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9791236D2C47 for <tls@ietf.org>; Thu, 19 Jun 2025 00:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1750319554; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=NE0QAn2+BkyJk9EpdDAb2v5UsD1EfOfo4lHaL7nPGsg=; b=FaID+5p9/8WlnKpGW9fyF1vpgtDjfFobIiy52w8T/wlG65ptiapfeoGkKdG5idHW6Z6wM b0gc02mouZsk6vcQ39XdC2vt0ifz1UWlJNr04cgC/fFJ9+2rIk6VYQZe1cS5CxHCxeP5IxY tokE6kvIZWnDyXhQGwHI/XANhl3vr48=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id BAF14868D31; Thu, 19 Jun 2025 17:52:34 +1000 (AEST)
Date: Thu, 19 Jun 2025 17:52:34 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <aFPBwrrRNAPsOeZJ@chardros.imrryr.org>
References: <45jp5tle7ixk7xhc57j5extnhg772nhhguqp4arvuppjuotkdo@jq5vd74bdpbg> <CAF8qwaAj8rYkRWatDuxmBQ+TQu7Yw1GPNm-Jf+W1CT0j18nwBg@mail.gmail.com> <aFOipMpzLkQa1Aaa@chardros.imrryr.org> <ed038d80-59e3-4a22-bf1c-f14968e0441b@app.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <ed038d80-59e3-4a22-bf1c-f14968e0441b@app.fastmail.com>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 7TP2K3XVWRGDKY345STBC3RCCAUEJ6DP
X-Message-ID-Hash: 7TP2K3XVWRGDKY345STBC3RCCAUEJ6DP
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: tls@ietf.org
Subject: [TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dAgvQsaYwx6TTq3twRdOybUDwP4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Thu, Jun 19, 2025 at 09:29:06AM +0200, Filippo Valsorda wrote:

> 2025-06-19 07:39 GMT+02:00 Viktor Dukhovni <ietf-dane@dukhovni.org>:
> > On Tue, Jun 17, 2025 at 02:16:19PM -0400, David Benjamin wrote:
> > 
> > > This draft is not the way to solve this problem.
> > 
> > I should mention, that though that is also my reaction, we are by no
> > means on the same page here.  I find the Google position in:
> > 
> >     https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarchies
> > 
> > to be substantively indefensible.  Google are not merely saying that
> > Chrome will not trust certificates with a "mixed" client/server EKU
> > (which is a nuisance position I can live with), rather they are coërcing
> > the CAs to not issue any client certificates even for non-Chrome
> > use-cases.
> 
> No, they are requiring CAs who wish to have a root included in Chrome
> for the purposes of TLS server authentication to issue roots dedicated
> to TLS server authentication.
> 
> CAs as entities can operate multiple roots and are not constrained in
> what they issue from other roots. (That would be indeed outrageous!)

And which roots are these that are dedicated to non-web use-cases?  And
is the rationale for this sort of domain separation at the root CA layer
at all compelling?  One might, for example, instead dedicate to this end
intermediate issuer CAs having a serverAuth EKU, that will in many (be
they for now ad hoc, rather than RFC5280-blessed) TLS stacks be
intepreted as restricting any issued EE certificates to that EKU
(implicit or explicit).

Imposing the requirement on the root CAs, rather than on the EE
certificates considered valid, seems rather dramatic overreach.

If this remains in effect long-enough, ugly work-arounds should
be expected.

-- 
    Viktor.

v2.32.0 | Report a Bug | By Email | System Status