[openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
On Wed Feb 10 21:59:12 2016, [hidden email] wrote:

> Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016"
>
> Command: "openssl x509 -inform der -in sample_ekcert.der"
>
> Result:
> "unable to load certificate
> 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal
> padding:a_int.c:223:
> 140618483803816:error:0D08303A:asn1 encoding
> routines:asn1_template_noexp_d2i:nested asn1
> error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF
> 140618483803816:error:0D08303A:asn1 encoding
> routines:asn1_template_noexp_d2i:nested asn1
> error:tasn_dec.c:648:Field=cert_info, Type=X509"
>

As the error is suggesting it doesn't like the serialNumber in the certificate.
If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you get:

13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB DA
: Error: Integer '00 59 ...' has non-DER encoding.


The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain
leading zeroes. OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter.

What was the certificate generated with?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
This is the Endorsement Key certificate extracted from a TPM device.

On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT <[hidden email]>
wrote:

> On Wed Feb 10 21:59:12 2016, [hidden email] wrote:
> > Version: "OpenSSL 1.1.0-pre2 (alpha) 14 Jan 2016"
> >
> > Command: "openssl x509 -inform der -in sample_ekcert.der"
> >
> > Result:
> > "unable to load certificate
> > 140618483803816:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal
> > padding:a_int.c:223:
> > 140618483803816:error:0D08303A:asn1 encoding
> > routines:asn1_template_noexp_d2i:nested asn1
> > error:tasn_dec.c:648:Field=serialNumber, Type=X509_CINF
> > 140618483803816:error:0D08303A:asn1 encoding
> > routines:asn1_template_noexp_d2i:nested asn1
> > error:tasn_dec.c:648:Field=cert_info, Type=X509"
> >
>
> As the error is suggesting it doesn't like the serialNumber in the
> certificate.
> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
> get:
>
> 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB DA
> : Error: Integer '00 59 ...' has non-DER encoding.
>
>
> The problem is that is an invalid encoding. An ASN.1 INTEGER cannot contain
> leading zeroes. OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is
> stricter.
>
> What was the certificate generated with?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
> Please log in as guest with password guest if prompted
>
>

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Rich Salz via RT
>On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT <[hidden email]>

>wrote:
>>On Wed Feb 10 21:59:12 2016, [hidden email] wrote:
>>As the error is suggesting it doesn't like the serialNumber in the
>>certificate.
>> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
>> get:
>>
>> 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB
>>DA
>> : Error: Integer '00 59 ...' has non-DER encoding.
                      ^^^^^
Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
even without the leading zero byte. See below.

>>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
>>contain
>> leading zeroes.

I’m pretty sure this is not correct. It’s been a while since I touched
ASN.1, but I had quite a bit of experience with it back when. SO first of
all, could you please cite your (authoritative) sources stating that an
ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others
<http://stackoverflow.com/questions/5974633/asn-1-der-formatted-private-key
> had to say about this:

        The private key values are encoded as ASN.1 INTEGERs, which are signed
values
        in two's complement format. The leading zero byte is necessary when the
MSB of
        the (unsigned) RSA key value is set. Having the MSB set without a leading
zero
        byte would mean a negative value.


        The ASN.1 specs are free and are linked from Wikipedia
        <http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One>.
        The relevant section here is in X.690, "8.3 Encoding of an integer value”.


In short, the problem is that without that leading zero there is no way to
tell a negative integer from a positive integer.

Here’s how the *current* OSS Nokalva ASN.1 compiler
<http://asn1-playground.oss.com/> DER-encodes integers. First, the ASN.1
spec (had to wrap in a sequence to avoid jostling with the compiler, as I
don’t remember how to write definitions of single primitive types)

World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
   Tst ::= SEQUENCE {
       value INTEGER (-256..257)
   }
END


And playing with different integer values in the given range:

my-tst Tst ::=
{
   value 127
}


Encodes to 3003 02017F (relevant parts: tag 02, len 01, value 7f)

However this:

my-tst Tst ::=
{
    value 128
}


Encodes to 3004 02020080 (integer tag 02, len *02*, and value 00 80) and
for a VERY good reason! If you try to decode the following

3003020180 (what you seem to suggest - the number without the leading
zero) you get:

ASN1STEP: Decoding PDU #1 :

Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3

value INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
-128

Successfully decoded 5 bytes.
rec1value Tst ::=
{
    value -128
}


Notice that minus.



>>OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter.


I say OpenSSL-1.1 got this wrong, and needs to be fixed.

P.S. Sticking the value of the integer provided provided by Cristian into
OSS ASN.1 DER decoder gave:

         OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :
Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 22
D0022E: Integer or enumerated value needlessly long; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
D0023E: Integer or enumerated value too long: 19; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
  value INTEGER: tag = [UNIVERSAL 2] primitive; length = 20
    2147483647
S0012E: Decoding of PDU #1 failed with the return code '5'.



Trimming the leading zero from the value (as for *this* particular integer
value that zero is not needed to disambiguate between + and -):

          OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.

ASN1STEP: Decoding PDU #1 :
Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 21
D0023E: Integer or enumerated value too long: 19; check field 'value'
(type: INTEGER) of PDU #1 'Tst'.
  value INTEGER: tag = [UNIVERSAL 2] primitive; length = 19
    2147483647
S0012E: Decoding of PDU #1 failed with the return code '10'.



The following might also be useful (attempting to encode/decode integer
value 128).

Schema

World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
  Human ::= INTEGER (0..257)
END

Data: 020180

Decoding:

         OSS ASN-1Step Version 7.1
Copyright (C) 2014 OSS Nokalva, Inc.  All rights reserved.
This product is licensed for use by "OSS Nokalva, Inc."

C0043I: 0 error messages, 0 warning messages and 0 informatory messages
issued.


ASN1STEP: Decoding PDU #1 :

D0076S: A negative unsigned integer encountered; check PDU #1 'Human'.
S0012E: Decoding of PDU #1 failed with the return code '2'.


The error is correct: decoded value by the rules of decoding is negative,
but the type restriction said it had to be unsigned, aka non-negative.




--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Salz, Rich
If arbitrary leading zero's were allowed in DER, then the encoding wouldn't be *distinguished*, i.e., unique.

In BER, almost anything goes :)

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Blumenthal, Uri - 0553 - MITLL
On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
<[hidden email] on behalf of [hidden email]> wrote:

>If arbitrary leading zero's were allowed in DER, then the encoding
>wouldn't be *distinguished*, i.e., unique.

I am NOT talking about “arbitrary” leading zeros. I explicitly state (and
cite the sources, might add the ASN.1 standard itself, and “ASN.1
Complete” by John Larmouth) that a leading zero *is* necessary and
required for a positive integer when its MSB is one (e.g., 0x80). In other
cases it indeed does not belong.

>In BER, almost anything goes :)

We are *explicitly* and *exclusively* discussing DER. Anything goes for
Bear. :-)

P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the
first “valuable” byte was 0x59), so the leading zero byte did not belong.
But I hope OpenSSL-1.1 would properly process 0x02020080.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Salz, Rich
Testing the previous Github version of OpenSSL-1.1 produced encouraging
results (notice the leading zero, right where it belongs):

$ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
hexdump -C d.der
    0:d=0  hl=2 l=   2 prim: INTEGER           :80
00000000  02 02 00 80                                       |....|
00000004
$ dumpasn1 d.der
  0   2: INTEGER 128

0 warnings, 0 errors.
$




P.S. dumpasn1.c doesn’t seem to parse negative integers correctly:

$ x=-128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
hexdump -C d.der
    0:d=0  hl=2 l=   1 prim: INTEGER           :-80
00000000  02 01 80                                          |...|
00000003
$ dumpasn1 d.der
  0   1: INTEGER 128
       :   Error: Integer has a negative value.

0 warnings, 1 error.
$


--
Regards,
Uri Blumenthal





On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
<[hidden email] on behalf of [hidden email]> wrote:

>If arbitrary leading zero's were allowed in DER, then the encoding
>wouldn't be *distinguished*, i.e., unique.
>
>In BER, almost anything goes :)
>
>--
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Viktor Dukhovni

> On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> Testing the previous Github version of OpenSSL-1.1 produced encouraging
> results (notice the leading zero, right where it belongs):
>
> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der &&
> hexdump -C d.der
>    0:d=0  hl=2 l=   2 prim: INTEGER           :80
> 00000000  02 02 00 80                                       |....|
> 00000004

There's no leading zero in this example.  Don't confuse zero nibbles
with zero octets.

--
        Viktor.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Salz, Rich
In reply to this post by Blumenthal, Uri - 0553 - MITLL
> Larmouth) that a leading zero *is* necessary and required for a positive
> integer when its MSB is one (e.g., 0x80). In other cases it indeed does not
> belong.

Agreed.  Perhaps I mis-read your note.  Sorry.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Richard Levitte - VMS Whacker-2
In reply to this post by Blumenthal, Uri - 0553 - MITLL
Let's put this to rest, shall we?

    : ; cat > checkasn1int.sh
    #! /bin/sh
   
    CMD="$@"
   
    for x in "3003 02011F" \
             "3003 020180" \
             "3004 0202001F" \
             "3004 02020080"; do
        echo Trying sequence $x
        echo $x | xxd -r -ps | $CMD
    done
    : ; sh checkasn1int.sh openssl asn1parse -inform d -i
    Trying sequence 3003 02011F
        0:d=0  hl=2 l=   3 cons: SEQUENCE          
        2:d=1  hl=2 l=   1 prim:  INTEGER           :1F
    Trying sequence 3003 020180
        0:d=0  hl=2 l=   3 cons: SEQUENCE          
        2:d=1  hl=2 l=   1 prim:  INTEGER           :-80
    Trying sequence 3004 0202001F
        0:d=0  hl=2 l=   4 cons: SEQUENCE          
        2:d=1  hl=2 l=   2 prim:  INTEGER           :1F
    Trying sequence 3004 02020080
        0:d=0  hl=2 l=   4 cons: SEQUENCE          
        2:d=1  hl=2 l=   2 prim:  INTEGER           :80
    : ; openssl version
    OpenSSL 1.0.2f  28 Jan 2016
    : ; sh checkasn1int.sh util/shlib_wrap.sh apps/openssl asn1parse -inform d -i
    Trying sequence 3003 02011F
        0:d=0  hl=2 l=   3 cons: SEQUENCE          
        2:d=1  hl=2 l=   1 prim:  INTEGER           :1F
    Trying sequence 3003 020180
        0:d=0  hl=2 l=   3 cons: SEQUENCE          
        2:d=1  hl=2 l=   1 prim:  INTEGER           :-80
    Trying sequence 3004 0202001F
        0:d=0  hl=2 l=   4 cons: SEQUENCE          
        2:d=1  hl=2 l=   2 prim:  INTEGER           :BAD INTEGER:[001F]
    Trying sequence 3004 02020080
        0:d=0  hl=2 l=   4 cons: SEQUENCE          
        2:d=1  hl=2 l=   2 prim:  INTEGER           :80
    : ; util/shlib_wrap.sh apps/openssl version
    OpenSSL 1.1.0-pre3-dev  xx XXX xxxx
    : ;

Cheers,
Richard

In message <D2E24B89.26F4D%[hidden email]> on Thu, 11 Feb 2016 19:37:18 +0000, "Blumenthal, Uri - 0553 - MITLL" <[hidden email]> said:

uri> On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich"
uri> <[hidden email] on behalf of [hidden email]> wrote:
uri>
uri> >If arbitrary leading zero's were allowed in DER, then the encoding
uri> >wouldn't be *distinguished*, i.e., unique.
uri>
uri> I am NOT talking about “arbitrary” leading zeros. I explicitly state (and
uri> cite the sources, might add the ASN.1 standard itself, and “ASN.1
uri> Complete” by John Larmouth) that a leading zero *is* necessary and
uri> required for a positive integer when its MSB is one (e.g., 0x80). In other
uri> cases it indeed does not belong.
uri>
uri> >In BER, almost anything goes :)
uri>
uri> We are *explicitly* and *exclusively* discussing DER. Anything goes for
uri> Bear. :-)
uri>
uri> P.S. In the integer value provided by Cristian, indeed the MSB was 0 (the
uri> first “valuable” byte was 0x59), so the leading zero byte did not belong.
uri> But I hope OpenSSL-1.1 would properly process 0x02020080.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Viktor Dukhovni
>>On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL

>><[hidden email]> wrote:
>>
>> Testing the previous Github version of OpenSSL-1.1 produced encouraging
>> results (notice the leading zero, right where it belongs):
>>
>> $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib
>> ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der
>>&&
>> hexdump -C d.der
>>    0:d=0  hl=2 l=   2 prim: INTEGER           :80
>> 00000000  02 02 00 80                                       |....|
                    ^^ this is the leading zero

>There's no leading zero in this example.

But there is - “00 80” rather than “80”.

>Don't confuse zero nibbles with zero octets.

Thank you, I don’t. :)

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Erwann Abalea-4
In reply to this post by Blumenthal, Uri - 0553 - MITLL
Bonjour,

Le 11 févr. 2016 à 20:25, Blumenthal, Uri - 0553 - MITLL <[hidden email]> a écrit :

On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT <[hidden email]>
wrote:
On Wed Feb 10 21:59:12 2016, [hidden email] wrote:
As the error is suggesting it doesn't like the serialNumber in the
certificate.
If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you
get:

13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB
DA
: Error: Integer '00 59 ...' has non-DER encoding.
                     ^^^^^
Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
even without the leading zero byte. See below.

The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
contain
leading zeroes.

I’m pretty sure this is not correct. It’s been a while since I touched
ASN.1, but I had quite a bit of experience with it back when. SO first of
all, could you please cite your (authoritative) sources stating that an
ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others
<http://stackoverflow.com/questions/5974633/asn-1-der-formatted-private-key
had to say about this:

X.690 edition 2015/08 is freely downloadable from the ITU-T website.
Section 8.3 describes how an INTEGER is to be encoded in BER.
8.3.2 says:

If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet:

a) shall not all be ones; and

b) shall not all be zero.

NOTE These rules ensure that an integer value is always encoded in the smallest possible number of octets. 

In this specific example (00 59 …), the bits of the first octets and bit 8 of the second octet are all zero. This is invalid.

There is no additional rule for DER on INTEGERs.

Cordialement,
Erwann Abalea


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Kurt Roeckx
In reply to this post by Blumenthal, Uri - 0553 - MITLL
See X.690, 8.3.2:
If the contents octets of an integer value encoding consist of more than
one octet, then the bits of the first octet and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE - These rules ensure that an integer value is always encoded
in the smallest possible number of octets.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Dr. Stephen Henson
In reply to this post by Blumenthal, Uri - 0553 - MITLL
On Thu, Feb 11, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

>                       ^^^^^
> Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
> even without the leading zero byte. See below.
>
> >>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
> >>contain
> >> leading zeroes.
>
> I???m pretty sure this is not correct. It???s been a while since I touched
> ASN.1, but I had quite a bit of experience with it back when.
>

I should've been a bit clearer. I should have said additional or superfluous
leading zeroes which is the cases here because there is a leading zero and the
MSB of the second octet is also zero. Others have referenced the relevant
sections of the standards that require that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Thu Feb 11 07:11:17 2016, [hidden email] wrote:
> This is the Endorsement Key certificate extracted from a TPM device.
>

Does it always do that or is this just an oddity?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
The EK certificate is generated and burned into the TPM during
manufacturing. The extraction operation always returns the same certificate.

On Thu, Feb 11, 2016 at 11:16 PM, Stephen Henson via RT <[hidden email]>
wrote:

> On Thu Feb 11 07:11:17 2016, [hidden email] wrote:
> > This is the Endorsement Key certificate extracted from a TPM device.
> >
>
> Does it always do that or is this just an oddity?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
> Please log in as guest with password guest if prompted
>
>

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Thu Feb 11 21:38:18 2016, [hidden email] wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev