Re: [TLS] Delegated Credentials Question about PSS

"Martin Thomson" <mt@lowentropy.net> Mon, 21 October 2019 22:34 UTC

Return-Path: <mt@lowentropy.net>
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 ED622120A68 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 15:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=FwzaOIAT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=anaNnaMy
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 FIb7dlIXUCql for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 15:34:18 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA7C120018 for <tls@ietf.org>; Mon, 21 Oct 2019 15:34:18 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 48C2C6CA; Mon, 21 Oct 2019 18:34:17 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 21 Oct 2019 18:34:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=iSDpurON5HflBYsYQty6AfHvehMh rCR1OunSgqOKxF8=; b=FwzaOIATcyGgU3a3TM0kdO2iLKp/DDlOPCQau6T6BYE7 F96d/iKtz0da6BDK1tgXsC53kDZUCGOCDn3S8DG8c34avEh23eoXnM7Glf3LykWt htPvrK3mOlF2LMGcH/NVCAciPMPl6BzGnECk/Zf3zETQ7IDskD5qAqSEn9P7aTbG GM2X9rhNjfGJA0hNyHuYUyms4HnzOcBGaWd3LhU+RVOJVbdGrTgi0haV+niwRTcT GjT3KD+JxTHhGEJk4W66340pmbO7K/v+IYHYm2LVgwXyMG1q99T6Gfyx1r3taCaS XgZA6HZJ2HWl+PkppK8Oufw9aspprevH/JfcM1nc0Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=iSDpur ON5HflBYsYQty6AfHvehMhrCR1OunSgqOKxF8=; b=anaNnaMysfSnzkjdCIHY+v lhSFuRXdqoAPHmZ40kLoZ+88Zd80ql0+7/byQrzMSJ/6TI5oWLoMrc3vkYYSfTyF uFy58gPYN2GUCSJOaSAMZtBZWtV1rx7fKBSorEkUihTezFIQIR9BHRwM/PXACiJN axwC9m6NwkrNDrWW/Wf/6CMb1cnKnpSe/qBcqb/sbAyd28/TDk7I+PAq7D2E8f4U kN2GOC9g09pty2voIbu3BfgWcFCOMiHp5RfU21UtXDBCA9CmLoGnKdY33r+6X3He IqQuKSVSt76Qur110xcLzss3bq/ojuh8PD4zJgOC58Nd8XPmyyu/8l92/QJI7qnA ==
X-ME-Sender: <xms:aDKuXZYPo_EgTmQ6B3MPOyb-Vg5SC-W6MAOTeilrlFhi9MFzyYi-XA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeigdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:aDKuXfmBgaSZ3Dt_3heOdeYdBokoN8kVTkleLJsqSrSdR5V4Ms415Q> <xmx:aDKuXep3p-IGm5WnkACpjROYX-jcKzAbSr07cZVrCcDm91xPqk6guA> <xmx:aDKuXRCEEzeafOdxraMWopGzvikfi76IBwJAYPIP4LxQm-wdfcJVdQ> <xmx:aDKuXaN3ltjwcL_k1ajW7Da2rvtS6jZl7_GDEFLPpYD5KrGxRdCQFg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67965E00A5; Mon, 21 Oct 2019 18:34:16 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4
Mime-Version: 1.0
Message-Id: <975f9484-7206-469d-a57a-7b8dc67bd53e@www.fastmail.com>
In-Reply-To: <CACsn0cnYc3nkMh9ajB_b8L=MZpd_r6yuP+=RPgAu2s-MGpdWmQ@mail.gmail.com>
References: <CAFDDyk-ohwH4pfeen8iFRHCqb8Pb95-DagORA_NtgaG9AWyoMQ@mail.gmail.com> <D11B62D0-2970-478F-A987-CECB45D58976@vigilsec.com> <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> <CAFDDyk-oEr=s5XFqAoXWe8kqMwf=RNzLJXFfezctZ=pAG7kK3A@mail.gmail.com> <7d15a1f1-c646-43b7-b5d6-c89ea4b4b615@www.fastmail.com> <CACsn0cnYc3nkMh9ajB_b8L=MZpd_r6yuP+=RPgAu2s-MGpdWmQ@mail.gmail.com>
Date: Tue, 22 Oct 2019 09:33:56 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Nick Sullivan <nick@cloudflare.com>, TLS List <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kDmxrNB1iG8OeVgardF_tp9LnIw>
Subject: Re: [TLS] Delegated Credentials Question about PSS
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, 21 Oct 2019 22:34:20 -0000

On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote:
> In TLS 1.3 it seems to have been assumed this wouldn't happen and we 
> could split signature algorithms from signature algorithms cert.
> 
> If that's not actually the case it affects more than just DCs. DCs are 
> a good way to restore extensibility if there is a problem here, 
> provided we can come up with a solution.

Yeah, I think that this is the clincher.

FWIW, in Firefox we have a separation between TLS and the certificate validation logic.  The latter cares about the SPKI of all certificates in the certification path because it applies policy related to choice of keys.  As a result, that code cares about DC also.  So we don't really get to advertise an algorithm until it is supported in both places.  For that reason signature_algorithms_cert, as much as it is intended to address this sort of split, doesn't really help us.

Logically, there is a split between the certification path construction and the policy pieces, and the structure of the code recognizes this, but in practice they are somewhat coupled.