I've added support for leading zeroes in the ASN1 length octets which will also
address this bug. For now it's only in the master branch.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_
On Sat Jun 28 05:53:36 2014, rsalz wrote:
> As discussed, the "failed" encoding is BER, not DER, and we only do
> DER. (And
> if you know what that means, and the difference between the two, you
> have my
> sympathies.)
Actually we *do* do BER in general for decoding and in a number of places
enco
As discussed, the "failed" encoding is BER, not DER, and we only do DER. (And
if you know what that means, and the difference between the two, you have my
sympathies.)
__
OpenSSL Project http://www.
As discussed, the "failed" encoding is BER, not DER, and we only do DER. (And
if you know what that means, and the difference between the two, you have my
sympathies.)
__
OpenSSL Project http://www.
Am 5. März 2012 16:45 schrieb Martin Boßlet :
> I'm sorry, but I disagree - this is not a legal encoding, even not at the end
> of a constructed indefinite length encoding.
>
> The first 0x00 cannot belong to a multiple length encoding because section
> 8.1.3.5 of X.690 states that bit 8 would hav
> "84 00 00 00" (three zero octets) would be a valid encoding
> (context-specific tag 0,
> zero length followed by and END OF CONTENTS),
Sorry, this has to read context-specific tag 4 of course.
Best regards,
Martin Bosslet
__
Op
Am 5. März 2012 15:14 schrieb Stephen Henson via RT :
>> [steve - Fri Mar 02 03:57:59 2012]:
>>
>> > [to...@tutus.se - Thu Mar 01 15:44:36 2012]:
>> >
>> > Hi,
>> >
>> > In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
>> > parser that if one has length data such as
>> >
>> >
Le 05/03/2012 15:14, Stephen Henson via RT a écrit :
>> [steve - Fri Mar 02 03:57:59 2012]:
>>
>>> [to...@tutus.se - Thu Mar 01 15:44:36 2012]:
>>>
>>> Hi,
>>>
>>> In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
>>> parser that if one has length data such as
>>>
>>> 84 00 00
Le 05/03/2012 15:14, Stephen Henson via RT a écrit :
[steve - Fri Mar 02 03:57:59 2012]:
[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a block to
> [steve - Fri Mar 02 03:57:59 2012]:
>
> > [to...@tutus.se - Thu Mar 01 15:44:36 2012]:
> >
> > Hi,
> >
> > In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
> > parser that if one has length data such as
> >
> > 84 00 00 00 00
> >
> > at the end of a block to be parsed,
> [to...@tutus.se - Thu Mar 01 15:44:36 2012]:
>
> Hi,
>
> In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
> parser that if one has length data such as
>
> 84 00 00 00 00
>
> at the end of a block to be parsed, it will give "header too long" error
> even though the ASN.1
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a block to be parsed, it will give "header too long" error
even though the ASN.1 is valid. This is because the supplied max value
to asn1_get_length(
12 matches
Mail list logo
