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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IZ-Blskhv6E2Aisd0OZ5NbSDIxI>
Subject: Re: [TLS] 
 =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?=
 =?utf-8?q?erratum=3F?=
Precedence: list

--nextPart20131096.QqXdQT4Jjt
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

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.
>=20
> > -----Original Message-----
> > From: TLS <tls-bounces@ietf.org> On Behalf Of Hubert Kario
> > Sent: Monday, September 30, 2019 8:56 AM
>=20
> ...
>=20
> > At the same time SEC 1 v2.0[1] defines that structure as follows:
> >            ECDSA-Sig-Value ::=3D SEQUENCE {
> >           =20
> >                r INTEGER,
> >                s INTEGER,
> >                a INTEGER OPTIONAL,
> >                y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL
> >           =20
> >            }
[snip]=20
> 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 octe=
t=20
length

so the above quoted structure with "a" and "y" omitted will be bit for bit=
=20
identical with the ECDSA-sig-value structure defined in X9.62-2005 (Thanks=
=20
Peter for providing the relevant section). So for "traditional" format of=20
signatures, they will be compatible, it's when an implementation starts to =
be=20
"helpful" by providing those additional values that SEC1 implementation wil=
l=20
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).
>=20
> Of course, the strictly proper way to do (2) was to have put an ASN.1 "..=
=2E"
> placeholder in the old syntax, thereby accommodating for future extension=
s.
> 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=20
encoded with DER, not BER
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
--nextPart20131096.QqXdQT4Jjt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2TS2EACgkQkqjRuAHS
9fUAGxAAl8FpTBLThPGJ9+KiQ67gCmzz3NLr5OXkHCta48lS3WBVCT7lluHrRbG9
+fjuUZnDkFT5518H2p5aX4X+S72YD7A9zn/okwTaKMoaA6nZC011qYpSlucrHOmK
BZpSIGYzO9CEZJWt+ANuh5QkzVy7hFWyZCK1iCbXY5IuunQih4s9ygemZm1ar8dR
3eonN96AHZh6qdsFVzgrMaoMeVYQ65rD1yX0KohxvJYrQD2kWXBNs7tk8o7kdQrv
o3PN7WTgsdfLVIu22Vk/lVkNZwiMWIdi20rJOw/i6u9poR5367Ojum/YP9fdw6q7
5xi2B6fimUDBG+ePWqtOP6FkmayFZayCyaedApKeN8e+I0mix+8rD2xHlvtwvqAW
KvY0h1Whs5RNItq3CBx761QR7YgJzXiQqXadTWkf7duRc5iafgLOcgU7Rfest08s
1VwiqVR1FSFtAvQYOK00nkYSfUNfxqy3BQpM4gtixWrFDIkDhhScOevVhrfHGuVh
t9084RLibDUgsBgJ0V+UhXegrhS6k0BjVwUm797hD5NhqH4OKVLi/gQyDBWQfRtS
4M5wCQ5J7rZTzNnaPHy5KBuEwTVfbbw1RzDfESnRDskVUoLjLt5V3iA6ppUsgaXF
C54FY5NPdkKzL5f4TOQXbxzZpM/w94f0e0R44OVuf6QaWfZAAq0=
=ux+S
-----END PGP SIGNATURE-----

--nextPart20131096.QqXdQT4Jjt--