Re: [TLS] Possible TLS 1.3 erratum

Hubert Kario <> Tue, 20 July 2021 10:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EB053A1C9D for <>; Tue, 20 Jul 2021 03:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 6Yh_2RR7ut11 for <>; Tue, 20 Jul 2021 03:38:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 427B63A1C9B for <>; Tue, 20 Jul 2021 03:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1626777532; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iXhZfMdbaonZzi/1TZEXOmTbkPSSxVs7NuZx/BY6nuE=; b=ArsXiNwrouTDw90HamSmXk982a/GyUQt811BPbjSNE415pce5783cEBu6w/4jfngiuSQWd aa6j9CHocLKYp/c5rEFoN9N0QpXd2Qq3gep8oRrPoB4SHXMtQC3NFPGFf6j6KG7jqAak9V IjpnE57XBjz4Ttn3YyZHVLiJcJ9UaTQ=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-259-25vB-B8HPUOxgRozndo4Bg-1; Tue, 20 Jul 2021 06:38:51 -0400
X-MC-Unique: 25vB-B8HPUOxgRozndo4Bg-1
Received: by with SMTP id y3-20020a17090614c3b0290551ea218ea2so2163413ejc.5 for <>; Tue, 20 Jul 2021 03:38:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:mime-version:message-id :in-reply-to:references:organization:user-agent :content-transfer-encoding; bh=uA7PA4geUuetjmbO3QdwomamJ3EzxYGzeQ5NasAEIO4=; b=jiTVMozEAppSjkZ9CrmdQOXxKeigN0yYxd9O4qIC+FfY6Y1dfBmK/+3Frwd8W6lm8X Liq9MjIqGMsVEKnu6hLPFmIiqDBl8yBllJNcNh9NaPgY1XVPOtS3vkOURs1T1+pjQWvj IEAMbBBL4Hv1ZG0+hCvhjTs8AUURoI8sA4WVanLXxyLwVsV6Kn7jwfeWJNzFycS9UrBP P1LmjlgiTwhnFTGaoTgt4rmgbg9ylZ4svE4cLSb0tWaLPK8GVrbd2t2F8cQy4Zx36cvQ H3wBgHEaNQqEHHBEasj/ewva50vasd0SisxGPh1xv3NroGi8eXAdduFtfb1/yOEPIpWx eRlw==
X-Gm-Message-State: AOAM533W+ijpxAfYEqvK7jVqZ7EHzu5k1BWWIYpOpO5XcK8NVGRZWs66 mR+t+F7VUXBK6ovu0eDF0/TaZo8t6ZywNg+vZ/JcAdDzbG4EfX/pQFAfuwOtFOB2F/qBKcx+7OZ tH0c=
X-Received: by 2002:a05:6402:4d1:: with SMTP id n17mr39326101edw.337.1626777530441; Tue, 20 Jul 2021 03:38:50 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzNCz/EaK7sF22OLx1olDoRF0dZ0Onq9TMonHIIxaDAtlg9gg53QUvZMJmBZodXVaHPPGq03w==
X-Received: by 2002:a05:6402:4d1:: with SMTP id n17mr39326079edw.337.1626777530213; Tue, 20 Jul 2021 03:38:50 -0700 (PDT)
Received: from localhost ( []) by with ESMTPSA id l1sm7054800ejk.17.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jul 2021 03:38:50 -0700 (PDT)
From: Hubert Kario <>
To: Peter Gutmann <>
Cc: Ilari Liusvaara <>,
Date: Tue, 20 Jul 2021 12:38:48 +0200
MIME-Version: 1.0
Message-ID: <>
In-Reply-To: <>
References: <>
Organization: Red Hat
User-Agent: Trojita/0.7-git; Qt/5.15.2; xcb; Linux; Fedora release 33 (Thirty Three)
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Possible TLS 1.3 erratum
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: Tue, 20 Jul 2021 10:39:01 -0000

On Monday, 19 July 2021 21:37:08 CEST, Peter Gutmann wrote:
> Hubert Kario <> writes:
>> It only doesn't matter if you don't want to verify the certificate...
>> It's one thing to be able to be able to verify an RSA-PSS signature on TLS
>> level, it's entirely another to be able to properly handle all 
>> the different
>> RSA-PSS limitations when using it in SPKI in X.509.
> Is there anything that's jumped through all the hoops to 
> implement the complex
> mess that is PSS but then not added the few lines of code you need do verify
> it in certificates?  And if so, why?

I suggest you go back to the RFCs and check exactly what is needed for 
handling of RSA-PSS Subject Public Key type in X.509. Specifically when the
"parameters" field is present.

You definitely won't be able to implement it in just "few lines".

> In any case it's still encoding a minor implementation artefact of the
> certificate library being used into the TLS protocol, where it 
> has absolutely
> no place.  You either do PSS or you don't, and the TLS layer doesn't need to
> know what magic number you use to identify it in certificates.

1. It's not minor
2. "What certificates can peer accept" is totally within the purview of 
   It's like that for Raw keys, it's like that for GPG certificates, it's
   like that for RSA vs ECDSA vs DSA certificates, and now it's also for
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic