Re: [TLS] Delegated Credentials Question about PSS

Nick Sullivan <> Thu, 24 October 2019 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B27CA120108 for <>; Thu, 24 Oct 2019 14:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QwxKFJ51EZdy for <>; Thu, 24 Oct 2019 14:04:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01683120847 for <>; Thu, 24 Oct 2019 14:04:43 -0700 (PDT)
Received: by with SMTP id d126so5638395vkb.1 for <>; Thu, 24 Oct 2019 14:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pr+xND91aNmtTUgHO4XUbtJPSnItiUPhc0Qm0Z0JKvM=; b=woGG/8lWr0VR3qqZocsZycR+fYUCCi0CyW4r5gLG2thv1dBIqDBiPpSxoIluHECc+p KORDGPyGqi2xRzL+Zh8m/GKfPQLjdd2UuvYX/OikQBPesHxu4PgVvkL0qHnwU5nUqADx FP9unC2q/UB33Wr+Mtkx4VJ7CeSK9bdASG4MI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pr+xND91aNmtTUgHO4XUbtJPSnItiUPhc0Qm0Z0JKvM=; b=pVHyj3Fnv6omXAE54XH3Q95PXlczb9LwV1Ei6KYD+LASxTvnnkTluZAShKxjDejGwZ EiGiIWWPCo7Q6sJ3iqVtJbpg45Pv89rbL/1pfnWblSwAmy+yeH8v6/8zOcM2Zv3ZYPte pydywtmjKdc5eo+wPjaIUQVxjUsZqkhoWLgOzCQM/F7fYD2rdKHZDYfS6blTHK4QmGgi MVeSu6UKNClCNcR/PlH+xqTGBRnfEoP8yrnsUnN453bOEagkF86YYJI3CXUL8df79rFY M9y3bTrFo6KdBNCMaa0eYEWNeAdj1ZIjvQG8H+VpL48fcHpW0tYE6I3FpZfTQU/7hSvY aqtw==
X-Gm-Message-State: APjAAAVzWtQiFdPJB6zJ+T7CHqmzgG8tsYuJ291l+GRjY5RsKoBs2bLp x7wuGpFdHc50cNXPX8XtEax4jmxl5yztNGhX/ROgRQ==
X-Google-Smtp-Source: APXvYqzxx38u17VojxjQH0RPiEDMgt4oxT611jIMvjTiYXlNJUPYum3Zhj0LyTrT+Tmq/A7sndcb9Fe+c4Ub1ofGC+w=
X-Received: by 2002:a1f:95ce:: with SMTP id x197mr248199vkd.19.1571951081635; Thu, 24 Oct 2019 14:04:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Thu, 24 Oct 2019 14:04:25 -0700
Message-ID: <>
To: Martin Thomson <>
Cc: Watson Ladd <>, TLS List <>, David Benjamin <>
Content-Type: multipart/alternative; boundary="000000000000d383bf0595ae6159"
Archived-At: <>
Subject: Re: [TLS] Delegated Credentials Question about PSS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2019 21:04:52 -0000

On Mon, Oct 21, 2019 at 3:34 PM Martin Thomson <> wrote:

> 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.

This makes sense. In the current text, signature_algorithms_cert only
applies to the cert chain, which is fine. It's slightly annoying that
supporting new SPKIs in DCs makes implementations have to support the new
SPKI in certificates, but it doesn't seem like too big of a deal.

I'd be interested in hearing from other client implementations on this
issue (cc: David Benjamin).