IETF Logo Mail Archive

Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Tue, 12 September 2017 17:36 UTC

Return-Path: <prvs=04280396fd=uri@ll.mit.edu>
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 28691132EC4 for <tls@ietfa.amsl.com>; Tue, 12 Sep 2017 10:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 mWU3dAcqj_98 for <tls@ietfa.amsl.com>; Tue, 12 Sep 2017 10:36:08 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2316E132EA7 for <tls@ietf.org>; Tue, 12 Sep 2017 10:36:07 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v8CHa57o025139; Tue, 12 Sep 2017 13:36:05 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
Thread-Index: AQHTKPY4UhEi4+aSakGFOcW9qXdI/qKwTHOAgAE+SwCAAAg8AIAAGaSAgAAeLAD//76AAA==
Date: Tue, 12 Sep 2017 17:36:04 +0000
Message-ID: <21C4A934-8B10-40A8-950F-0E7B61F08613@ll.mit.edu>
References: <20170908225948.GC31695@al> <1505225444.4161.35.camel@redhat.com> <68691b3c-3496-527c-e211-2a17a7c7b555@drh-consultancy.co.uk> <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com>
In-Reply-To: <5159391.MM5YjT3ssF@pintsize.usersys.redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-originating-ip: [172.25.177.12]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3588068164_1539450125"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-12_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709120245
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jKp1PBsixS4JWwcn92ZA96WjZXk>
Subject: Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 12 Sep 2017 17:36:10 -0000

   > . . . 
    > This could get pretty messy: it requires a logic not used in any other
    > algorithm. I'd be more than happy to have an outright prohibition on EE PSS
    > key parameter restrictions in TLS 1.3 so implementers don't have to bother
    > with this.
    
    what about hardware tokens that support only specific hashes or signatures?
    (I've seen ones that can do only RSA with SHA256 and SHA-1, but not SHA-384 or 
    SHA-512) Isn't it basically the same code path (though the limitation does 
    come from slightly different place).
   
I think that the requirement of having the same hash everywhere in this certificate takes care of this problem. 

If I’m missing the actual problem you’re pointing at – please outline the use case where it might manifest, and let’s take it from there.

v2.23.0 | Report a Bug | By Email