Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

[Hubert Kario <[e-mail]>]

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 <[e-mail]> 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