On 08/29/2010 01:20 PM, Mounir IDRASSI wrote:
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.
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".
You are citing out of context.
There is a reference to negative integers which can happen 50%.
A text written 10 years ago is not really an excuse for a certificate
from this year.
Moreover, major PKI libraries are tolerant vis-a-vis the encoding of the
serial number field of a certificate and they verify successfully the
certificate chain given by the original poster.
So what. The certs are still wrong.
For example, NSS, GnuTLS and CryptoAPI accept the given certificates and
verify successfully their trust.
hm, inserting the certs into Firefox says to me that the
certs cannot be validated for unknown reasons.
The decoders in NSS and GnuTLS accept all kinds of
bad encodings, the BER/DER decoders being very
Supporting or not specific broken implementations have always been the
subject of heated debates.
X509 has been updated to decode and reencode a certificate,
in this sense openssl's behaviour of silently dropping one
octet is not very nice. But there are other potential minor
Concerning the specific issue here, it's clear
that OpenSSL is too restrictive compared to other major libraries since
this is a minor deviation from the BER specs (i.e. minimal bytes
representation) and thus hurts deployments of real-world certificates.
Others are EXTREMLY permissive in decoding.
This minor deviation results in ambiguous DER. Assumed two
values 0001 or 01, are these the same serialnumber, or not?
This is asking for real trouble. Even when taking as a blob,
displaying will show 1 for both in "major" implementations.
I'd rather see openssl be more restrictive and reject bad encodings
(I am not talking about a negative number here).
and what about version:
some treat the second as a v3
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager majord...@openssl.org