Re: [TLS] [EXTERNAL] Re: Servers sending CA names

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 19 April 2023 02:59 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 AF96EC14CE44 for <tls@ietfa.amsl.com>; Tue, 18 Apr 2023 19:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiBklOMjLv9n for <tls@ietfa.amsl.com>; Tue, 18 Apr 2023 19:59:11 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FB9C14CE2C for <tls@ietf.org>; Tue, 18 Apr 2023 19:59:11 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id E4C3F125153; Tue, 18 Apr 2023 22:59:09 -0400 (EDT)
Date: Tue, 18 Apr 2023 22:59:09 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <ZD9Y_dW0ibnRaZct@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com> <ZDcbv4g5-tjN-Mu-@straasha.imrryr.org> <CAF8qwaBaOq1_Ow_vtB=DGjjDkAx+N+CPMpfn1huP=DRsCiFtaA@mail.gmail.com> <BY5PR00MB06757280F69B9C6D55AD2B048C9BA@BY5PR00MB0675.namprd00.prod.outlook.com> <accacacd-2bd6-4c89-8221-0c32b1a25ae3@betaapp.fastmail.com> <e5970ece-973b-e758-03b5-0e6ea2dc0b1b@redhat.com> <CAL02cgT0OyTP3F7qxTZvOXVv=X+=CywbYpYoE95MijPy5yshXQ@mail.gmail.com> <SY4PR01MB6251B265C49D63CC0EECBC22EE9D9@SY4PR01MB6251.ausprd01.prod.outlook.com> <91f409fb-79d9-ce73-9700-9d19b9ae0ab9@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <91f409fb-79d9-ce73-9700-9d19b9ae0ab9@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/051682h33TG4Vr2IIA3A8vHToV4>
Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 19 Apr 2023 02:59:15 -0000

On Tue, Apr 18, 2023 at 09:06:40PM -0300, Soni L. wrote:


> That seems particularly useful for federated networks (XMPP, etc). Why 
> not call these server-to-server certs?

That's basically it.  At least in OpenSSL, when a EKU extension is
present in the client certificate, it must allow client authentication
for the certificate check to pass validation.

However, some applications don't "validate" client certificates relative
to any trust anchor, and instead maintain explicit access control lists
of suitably authorised public keys (or enclosing certificates).

One low-volume, but actually employed use-case is
nullclient-to-smarthost MTA-to-MTA authentication, hence Postfix support
for relay access via client public key or cerificate fingerprints.

    https://www.postfix.org/postconf.5.html#relay_clientcerts
    https://www.postfix.org/postconf.5.html#check_ccert_access

The client certificate EKU is then irrelevant, but IIRC basicConstraints
may be enforced at the TLS layer (the certificate may need to be valid
for keyAgreement, the problem goes away with raw public keys :-).

-- 
    Viktor.