Nit: redundant leading 00 (or FF) in an INTEGER is VALID *B*ER
but INVALID *D*ER. And signed things like certs are *D*ER
for exactly this reason, so a reconstructed encoding is
bit for bit identical and hashes and signatures etc. work.
BER is already 'distinguished concerning the content
Hodie IV Kal. Sep. MMX, Mounir IDRASSI scripsit:
[...]
Specifically, Peter Gutmann in his X.509 Style Guide says this about this
field : If you're writing certificate-handling code, just treat the
serial number as a blob which happens to be an encoded integer.
This is the kind of advice that
У нед, 29. 08 2010. у 04:17 +0200, Mounir IDRASSI пише:
After some digging, I found that part of the problem is caused by the
functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file
crypto\asn1\a_int.c. At lines 244 and 314, there is an if block that
removes any leading zeros. Commenting
Hodie III Kal. Sep. MMX, Goran Rakic scripsit:
[...]
I read the other messages in this thread, but I am not an expert in the
field so I do not know if openssl should add a support for incorrect
serial numbers. In RFC 3280 there is a note about Non-conforming CAs
where section 4.1.2.2 Serial
On Mon, Aug 30, 2010, Goran Rakic wrote:
?? ??, 29. 08 2010. ?? 04:17 +0200, Mounir IDRASSI :
After some digging, I found that part of the problem is caused by the
functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file
crypto\asn1\a_int.c. At lines 244 and 314, there is
У пон, 30. 08 2010. у 20:38 +0200, Dr. Stephen Henson пише:
I wouldn't advise changing the code in that way (FYI I wrote it). The normal
workaround in OpenSSL for broken encodings is to use the original encoding
by caching it. The attached three line patch adds this workaround for
On Mon, Aug 30, 2010, Goran Rakic wrote:
?? ??, 30. 08 2010. ?? 20:38 +0200, Dr. Stephen Henson :
I wouldn't advise changing the code in that way (FYI I wrote it). The normal
workaround in OpenSSL for broken encodings is to use the original encoding
by caching it. The
The encoding is invalid BER.
The openssl is tolerant but also destructive in copy.
whenever you use openssl x509 -in -out ... you remove one leading 0 octet.
IMHO openssl should reject the cert because of invalid encoding.
On 08/29/2010 04:17 AM, Mounir IDRASSI wrote:
Hi,
The problem you
Hi Peter,
Although the certificate's encoding of the serial number field breaks the
BER specification about the minimal bytes representation, it is known that
many CA's and libraries treat this field as a blob and usually encode it
on a fixed length basis without caring about leading zeros.
On 08/29/2010 01:20 PM, Mounir IDRASSI wrote:
Hi Peter,
Although the certificate's encoding of the serial number field breaks the
BER specification about the minimal bytes representation, it is known that
many CA's and libraries treat this field as a blob and usually encode it
on a fixed length
On 08/29/2010 07:38 PM, Mounir IDRASSI wrote:
Hi Peter,
Thank you for your comments.
As I said, this kind of debates can be very heated and going down this
road don't lead usually to any results.
The debate may be whether and how something should be
done in openssl, I admit I had started
From: owner-openssl-us...@openssl.org On Behalf Of Peter Sylvester
Sent: Sunday, 29 August, 2010 05:44
The encoding is invalid BER.
The openssl is tolerant but also destructive in copy.
whenever you use openssl x509 -in -out ... you remove one
leading 0 octet.
IMHO openssl should
Hi all,
I have two X.509 certificates MUPCAGradjani.crt and MUPCARoot.crt
downloaded from http://ca.mup.gov.rs/sertifikati-lat.html
Certificate path is MUPCARoot MUPCAGradjani and I would like to
validate MUPCAGradjani against the other. What I did is to convert both
to PEM format and rename
Hi,
The problem you are encountering is partly caused by the way OpenSSL
handles integers whose DER encoded value starts with one or more zeros :
in this case, OpenSSL removes the leading zero when creating the
corresponding ASN1_INTEGER structure thus leading to the fact that
computed DER
14 matches
Mail list logo
