Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

Martin Thomson <> Sat, 29 November 2014 07:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F4A91A00E9 for <>; Fri, 28 Nov 2014 23:37:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id slT7BIkrABBw for <>; Fri, 28 Nov 2014 23:37:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E000A1A00B7 for <>; Fri, 28 Nov 2014 23:37:37 -0800 (PST)
Received: by with SMTP id wp18so5888561obc.29 for <>; Fri, 28 Nov 2014 23:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jzuLipfUQH9A/A8QtxY25qDcZhTGrH5THlZAvtenyeI=; b=WpQFuo1Gfo4tAfrJ6UJtjEffHsPV1YAEYT8J23VlthzBaC+iARpZCrJTU2UdmA4EgT A9ViVbpMUKzzKtS3yb1JM4v4RoghDWEc8L7r9t3MAKYal6aQVgUBsvTKqpmWNCFMZ18g wdUZfVgMgMs2qSwMX5EwJY2q7k3NEA5Z/KGF7Biusn3LBTa9PaZ+HPOVQF/nWQynWYn+ 9iV6wbL2te5EgxzTMnevlEtbo8+Pcqwnez/HfGO7ka42NWN1LyYN9TgJPNbgrn36MjFP yhTU99G7ZNW8BuQCkiE4xSo4Y70+QEH9C9PG3j/DG9P01/OPmZkILWYVcGfu/L7sBQK1 9DSg==
MIME-Version: 1.0
X-Received: by with SMTP id r195mr10614110oie.72.1417246657098; Fri, 28 Nov 2014 23:37:37 -0800 (PST)
Received: by with HTTP; Fri, 28 Nov 2014 23:37:36 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 28 Nov 2014 23:37:36 -0800
Message-ID: <>
From: Martin Thomson <>
To: Stephen Checkoway <>
Content-Type: text/plain; charset="UTF-8"
Cc: " (" <>
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
X-Mailman-Version: 2.1.15
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: Sat, 29 Nov 2014 07:37:39 -0000

On 27 November 2014 at 08:15, Stephen Checkoway <> wrote:
> Why should we require that the certificate be signed with the signature scheme corresponding to the public key?

If the certificate is selected based on the cipher suite (ECDSA, for
instance), maybe there is a desire to have a uniform chain so that a
client doesn't end up in a situation where they can't verify the chain
(because they don't have RSA, for example).

Now, we do have a lot of implementations that do both, so that's cool.
And we have other ways of advertising what signature methods are
available.  So, maybe this can be loosened to say that all
certificates in the chain MUST be supported by the client (as
determined by X, where X is TBD, mostly because I'm lazy).