Re: [TLS] Using RSA PSS in TLS

Johannes Merkle <> Mon, 28 October 2013 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74CE911E8112 for <>; Mon, 28 Oct 2013 05:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.531
X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r4U-O5zd-4Vk for <>; Mon, 28 Oct 2013 05:29:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D75D111E80F8 for <>; Mon, 28 Oct 2013 05:29:10 -0700 (PDT)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id CA32B1A0088; Mon, 28 Oct 2013 13:30:41 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id fIIkybbDRXUf; Mon, 28 Oct 2013 13:30:40 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 728BA1A0085; Mon, 28 Oct 2013 13:30:40 +0100 (CET)
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 13:29:08 +0100
Message-ID: <>
Date: Mon, 28 Oct 2013 13:29:07 +0100
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Santosh Chokhani <>, Rob Stradling <>, "<>" <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Oct 2013 12:29:08.0533 (UTC) FILETIME=[4C82D650:01CED3D9]
Subject: Re: [TLS] Using RSA PSS in TLS
X-Mailman-Version: 2.1.12
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: Mon, 28 Oct 2013 12:29:17 -0000

Santosh Chokhani schrieb am 14.10.2013 13:21:
> I was in error in the first place.  So, the original question remains of how to tell each other of PSS.

In TLS 1.2, the "signature_algorithms" extension is used to signal the supported / requested signature algorithms by
both client and server. In order to support PSS in that extension, a new code point (or several, depending on the PSS
parameters to be supported) had to be assigned in the corresponding IANA registry.

IMO it is not necessary to define new cipher suites. The semantics of "RSA" in cipher suites (and KeyExchangeAlgorithm
indicated in the the server key exchange messages) could be widened to comply with both PKCS#1v1.5 and PSS, and the use
of PSS would be defined eligible only if it has been signaled in the "signature_algorithms" extension by the other peer.
Likewise, the semantics of RSA in the certificate_types field in the Certificate Request message could be clarified that
an rsa key may refer to SPKI rsaPublicKey (general RSA key) as well as to SPKI id-RSASSA-PSS (PSS key), but that
PSS-keys are eligible only if PSS had been listed by the client in the signature_algorithms extension.

Thus, the changes seem limited and backward interoperability would be preserved in the specs.

Although the definition of new code points in the TLS SignatureAlgorithm Registry does not necessarily require a
standards track RFC, I am not sure if the change / extension of existing semantics in TLS 1.2 doesn't require the
standard track anyway.