A brief reminder below about 2 new extra elements of ECDSA-Sig-Value.
> -----Original Message-----
> From: TLS <tls-boun...@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
> }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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
