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-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
> >
> > }
[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?), andyes, 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
