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

[Dan Brown <[e-mail]>]

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
>            }

The new a and y values help a verifier recover the point R (where R=kG, and 
r=x(R) mod n, s=(e+dr)/k mod n), if desired.

Of course, it is possible to recover R from r, without a or y, but the 
downside is that such recovery seems to requiring test two different 
candidates for R.

There are a few small benefits of recovering R.

Faster verification: the verifier can verify as tsR=teG+trQ with a value t 
chosen to make both ts and tr small, which can be faster than using r alone.

Public-key recovery: the verifier can compute the signer's public key as Q = 
(1/r)(sR-eG).  The subtle sub-applications of Q-recovery include: 
proof-of-generation (if the message signed contains Q, then Q seems to be 
uniquely tagged), data compression (omitting Q from the cert), assisted key 
generation (a trusted authority adds entropy into Q).

I'm not sure if these applications are relevant to TLS, however.

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
 (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.