IETF Logo Mail Archive

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

kha.thach@gmail.com Wed, 19 April 2023 02:03 UTC

Return-Path: <kha.thach@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 80126C1522AB for <tls@ietfa.amsl.com>; Tue, 18 Apr 2023 19:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2akYp97N6EsC for <tls@ietfa.amsl.com>; Tue, 18 Apr 2023 19:03:04 -0700 (PDT)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 3A4CFC151B14 for <tls@ietf.org>; Tue, 18 Apr 2023 19:03:04 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-63b57c49c4cso2402894b3a.3 for <tls@ietf.org>; Tue, 18 Apr 2023 19:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681869783; x=1684461783; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=s0AqbSSu4bJy3ANqIZzd2Erf0/BwsRJ5txLG6JZCnYY=; b=Wm0sxV1iLJ4pszSfSwEbitTCIWvN+54jQmdiQA0AFijj8HIovLaIKO8beUV4m7s0Gs PyusRWJ88TgmZd4rrB3Y8m0CD9vIB6I+S/tSvsZwefcOjIgz2OfglnTXkwTc3HRVOtR0 UWO725kmrOEINdzkRySP+6TZnDoKRD2r0+aN32fZloDQv/VW/kh4KRXw5KLrNzJ855EU k3vOTALzvJ30RcVqOiSbAOrdQ6G4G4MvzBGR1EiD+sZfchtzhhzDkRPqHaJjcP47D158 aYr/eHARgtsHhzqtD0NSHKCbXNhAAMROC5Ui3vru47MqKTI7W7K28SKTTKKkPzOPjrPa HJiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681869783; x=1684461783; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=s0AqbSSu4bJy3ANqIZzd2Erf0/BwsRJ5txLG6JZCnYY=; b=hyL2s7jSU4m/5zcdmqU4WKYLgVeyaBAoKT9Vh8LVY6ECTtFuAR84hiiYVriHcFMn3M rLkqQyLehpTyZNogpYiruNr5t/XqL+MaiUI6+UgIr94nVvZPSdlLSZBQK932tDtrN0Cy 4DqHjRZUW9RYnG5BrAC5BKTG7wwDXy0iURFakaK2Ulqd5BcvsPvwElem541c6idPaDvf I3riEvZGb9xBkR1RgzOTQyxJLa7ViGVHmnIYH0SdvTwh0RUmOvkNKXKftCRAdJgcE7wY HaBeb2bZYaXwf2plSWQ513M6aCpF6tX4U0sx4oBbIGSe3OKXjDRgmAYNFodBuWv4eGor HsHg==
X-Gm-Message-State: AAQBX9f5NVf0ITcD7MQ3YU2U9xaRG6D9xif2ppAHzRFE2fmmGcAtlrqG FKSHQF0KXEFUVOsXy1TZF94=
X-Google-Smtp-Source: AKy350agMGDY0wcNEVZiTGnp6PyOx9DOhkDUan9D1GUlUDtMaFXFZptvyYIhkIWxupyXDP+7MPKAEw==
X-Received: by 2002:a05:6a00:98d:b0:63b:5496:7afa with SMTP id u13-20020a056a00098d00b0063b54967afamr1777833pfg.11.1681869783214; Tue, 18 Apr 2023 19:03:03 -0700 (PDT)
Received: from tckhathach ([210.2.100.130]) by smtp.gmail.com with ESMTPSA id e17-20020aa78c51000000b0063b79bae907sm6688968pfd.122.2023.04.18.19.03.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2023 19:03:02 -0700 (PDT)
From: kha.thach@gmail.com
To: 'Rushil Mehra' <rmehra=40cloudflare.com@dmarc.ietf.org>, "'Soni L.'" <fakedme+tls@gmail.com>
Cc: 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> <CAFHNucvEQBQnFA+sYcuvqBWPOZqD-fr=Dv+WCtiMbG+wREXGDg@mail.gmail.com>
In-Reply-To: <CAFHNucvEQBQnFA+sYcuvqBWPOZqD-fr=Dv+WCtiMbG+wREXGDg@mail.gmail.com>
Date: Wed, 19 Apr 2023 09:02:59 +0700
Message-ID: <0e6401d97263$12a87920$37f96b60$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E65_01D9729D.BF081470"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJgYLzOt4CBG5EhjxL+FQbylJTHJwKitG8cAWkJLucBVedkgQD6GfilAoLog+sBXXYICALPw4NfAoWtknUCPGiC5q2VkvCQ
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GUNNJlm9Xb-nUpHPEOG4i9FXifs>
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:03:08 -0000

Yes, and organization IT can even mark the private key associated with the client cert not exportable from that laptop.

I do have customers requiring client cert as one factor of authentication.

 

Thanks,

Kha Thach

 

From: TLS <tls-bounces@ietf.org> On Behalf Of Rushil Mehra
Sent: Wednesday, April 19, 2023 8:05 AM
To: Soni L. <fakedme+tls@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names

 

Not necessarily. One could use client certificates to ensure that only authorized clients (e.g. a laptop with the client certificate in its key store) can access some resource. 

 

On Tue, Apr 18, 2023 at 5:07 PM Soni L. <fakedme+tls@gmail.com <mailto:fakedme%2Btls@gmail.com> > wrote:

So like a "client" cert is just a way to say "yes I'm really 
example.org <http://example.org> " yeah?

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

On 4/18/23 20:45, Peter Gutmann wrote:
> Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx> > writes:
>
> >Let's Encrypt issues roughly 3 million publicly trusted certificates per day
> >that contain the client authentication EKU
>
> But they just set that by default for every cert they issue so it's pretty
> much meaningless.  There are public CAs that set keyAgreement for RSA certs,
> and emailProtection for TLS server certs, doesn't mean any of them ever get
> used for that.
>
> (My more snarky response would have been that I should have asked that the
> IETF define a peaceOnEarth EKU so Let's Encrypt could set that as well :-).
>
> Peter.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org> 
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/tls

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