From nobody Tue Apr 18 19:03:10 2023 Return-Path: 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 ; 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 ; 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 ; Tue, 18 Apr 2023 19:03:04 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-63b57c49c4cso2402894b3a.3 for ; 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: To: "'Rushil Mehra'" , "'Soni L.'" Cc: References: <51B56747-0347-43AB-93A7-C3FDF49902D2@akamai.com> <91f409fb-79d9-ce73-9700-9d19b9ae0ab9@gmail.com> In-Reply-To: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2023 02:03:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E65_01D9729D.BF081470 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. =20 Thanks, Kha Thach =20 From: TLS On Behalf Of Rushil Mehra Sent: Wednesday, April 19, 2023 8:05 AM To: Soni L. Cc: tls@ietf.org Subject: Re: [TLS] [EXTERNAL] Re: Servers sending CA names =20 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.=20 =20 On Tue, Apr 18, 2023 at 5:07 PM Soni L. > wrote: So like a "client" cert is just a way to say "yes I'm really=20 example.org " yeah? That seems particularly useful for federated networks (XMPP, etc). Why=20 not call these server-to-server certs? On 4/18/23 20:45, Peter Gutmann wrote: > Richard Barnes > 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 =20 > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0E65_01D9729D.BF081470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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> = wrote:

So like a = "client" cert is just a way to say "yes I'm really
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> = 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
> https://www.ietf.org/mailman/listinfo/tls

__= _____________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

------=_NextPart_000_0E65_01D9729D.BF081470--