Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
Hubert Kario <hkario@redhat.com> Tue, 01 October 2019 12:49 UTC
Return-Path: <hkario@redhat.com>
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 D426A1201A3 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 05:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 JvFsAAwO0OiU for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 05:49:44 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACB9120142 for <TLS@ietf.org>; Tue, 1 Oct 2019 05:49:44 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 57669C059B7C; Tue, 1 Oct 2019 12:49:44 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id CD4FA60464; Tue, 1 Oct 2019 12:49:43 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Dan Brown <danibrown@blackberry.com>
Cc: "TLS@ietf.org" <TLS@ietf.org>
Date: Tue, 01 Oct 2019 14:49:37 +0200
Message-ID: <2211799.0F6m8LsVZW@pintsize.usersys.redhat.com>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501E44E12@XMB116CNC.rim.net>
References: <1803994.nvTnDQYtSi@pintsize.usersys.redhat.com> <810C31990B57ED40B2062BA10D43FBF501E44E12@XMB116CNC.rim.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart20131096.QqXdQT4Jjt"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 01 Oct 2019 12:49:44 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IZ-Blskhv6E2Aisd0OZ5NbSDIxI>
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?
X-BeenThere: tls@ietf.org
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." <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, 01 Oct 2019 12:49:48 -0000
On Monday, 30 September 2019 16:40:57 CEST Dan Brown wrote: > A brief reminder below about 2 new extra elements of ECDSA-Sig-Value. > > > -----Original Message----- > > From: TLS <tls-bounces@ietf.org> On Behalf Of Hubert Kario > > Sent: Monday, September 30, 2019 8:56 AM > > ... > > > At the same time SEC 1 v2.0[1] defines that structure as follows: > > ECDSA-Sig-Value ::= SEQUENCE { > > > > r INTEGER, > > s INTEGER, > > a INTEGER OPTIONAL, > > y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL > > > > } [snip] > At the ASN.1 and DER formatting level, the intent was that > (1) old syntax signatures (r,s only) would be compatible with the new > syntax since optional fields are DER-encoded as empty strings, to empty > string should DER-decode (is this right?), and yes, in DER, OPTIONAL field that has no value results in a string of 0 octet length so the above quoted structure with "a" and "y" omitted will be bit for bit identical with the ECDSA-sig-value structure defined in X9.62-2005 (Thanks Peter for providing the relevant section). So for "traditional" format of signatures, they will be compatible, it's when an implementation starts to be "helpful" by providing those additional values that SEC1 implementation will start to fail to interoperate with X9.62 implementation. > (2) a lax, liberal implementation of the old syntax would understand the > new syntax, simply by ignoring the new values a and y, (and ignoring the > total length of the DER encoding). > > Of course, the strictly proper way to do (2) was to have put an ASN.1 "..." > placeholder in the old syntax, thereby accommodating for future extensions. > Alas, this was not put in. So a strict, literal implementation of the old > syntax should reject the new syntax. a lax DER parser sounds like an oxymoron to me... :) And I've checked, the TLS since the beginning was specifying signature as encoded with DER, not BER -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- [TLS] Ecdsa-sig-value in TLS 1.3 – need for errat… Hubert Kario
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Dan Brown
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Peter Gutmann
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Peter Gutmann
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… John Mattsson
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Dan Brown
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… John Mattsson
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Hubert Kario
- [TLS] (question on ANSI X9.62-2005) Re: Ecdsa-sig… Rene Struik
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Dan Brown
- Re: [TLS] (question on ANSI X9.62-2005) Re: Ecdsa… Dan Brown
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Eric Rescorla
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Peter Gutmann
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Dan Brown
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… John Mattsson
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Hubert Kario
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Hubert Kario
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Hubert Kario
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Sean Turner
- Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for e… Blumenthal, Uri - 0553 - MITLL