Hubert Kario writes:
>Now, I don't have access to X9.62-2005, but there's a possibility of
>confusion.
>From X9.62-2005:
E.8 Digital Signatures
When a digital signature is represented with ASN.1, the digital signature
shall be ASN.1 encoded using the following syntax:
ECDSA-Sig-Value
Hubert Kario writes:
>So I think the RFC 8446 should be updated with an erratum that specifies the
>source of the ECDSA-Sig-Value structure.
It looks like the SECG either defined their own gratuitously incompatible
version (since the X9.62 version has no extension markers) or accidentally
picked
A brief reminder below about 2 new extra elements of ECDSA-Sig-Value.
> -Original Message-
> From: TLS 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 ::= SEQUENC
On 30/09/2019 14:36, Christopher Wood wrote:
> On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
>> Clients must therefore
>> bound the number of parallel connections they initiate by the
>> number of tickets in their possession, or risk ticket re-use.
>> ```
>>
>> I'm not a
On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> > This version addresses some of the comments we received from Hubert a while
> > back. We think it's ready to go for WGLC, modulo whatever nits folks find.
> > :-)
>
> I
On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> This version addresses some of the comments we received from Hubert a while
> back. We think it's ready to go for WGLC, modulo whatever nits folks find.
> :-)
I still see the "vend" instead of "send" typos... Same for "vended"
tl;dr: there are conflicting definitions of ECDSA-Sig-Value structure, which
one "MUST" be used in TLS 1.3?
The ECDSA signature in TLS 1.3 (RFC 8446) is defined as follows:
ECDSA algorithms: Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANS
