[prev in list] [next in list] [prev in thread] [next in thread] 

List:       botan-devel
Subject:    [botan-devel] X509_Certificate.serial_number() leading zeros
From:       myles.shepherd () yahoo ! ca (Myles Shepherd)
Date:       2011-11-01 21:52:45
Message-ID: 1320184365.82924.YahooMailNeo () web121312 ! mail ! ne1 ! yahoo ! com
[Download RAW message or body]

?
Hello,

The second location was also an integer, but the casting to a BigInt did the trick:?

SecureVector<byte> serial = cert.serial_number();

pkcs7_encoder.encode(BigInt(serial.begin(), serial.size()),INTEGER, UNIVERSAL);


Thanks,
Myles

________________________________
From: Jack Lloyd <lloyd at randombit.net>
To: Myles Shepherd <myles.shepherd at yahoo.ca>; Botan development list <botan-devel at randombit.net>
Sent: Tuesday, November 1, 2011 1:56:17 PM
Subject: Re: [botan-devel] X509_Certificate.serial_number() leading zeros

On Tue, Nov 01, 2011 at 01:10:03PM -0700, Myles Shepherd wrote:
> Hello,
> 
> I noticed that?X509_Certificate.serial_number() truncates leading zeros.
> 
> My code creates a PKCS7 object. ?Since the PKCS7 object contains a
> signer's certificate, it encodes an entire X509 Certificate using
> X509_Certificate.BER_encode(). ?The ?X509_Certificate's serial
> number also goes in a second location in the PKCS7 object. ?To get
> this number, I initially used the .serial_number() method; however,
> if the serial number's leading zero is truncated, programs (such as
> Acrobat) no longer acknowledge the validity of the PKCS7 object
> (since the two serial numbers are different).

In the second location, is the serial number being stored as an octet
string or equivalent (vs being an integer type)? The leading zero is
an artifact of the DER encoding of integer values (twos complement,
with a leading zero byte being used to indicate a positive value which
has its high bit set - so this leading zero would not be there if, for
instance, 0x7fff was encoded). If you re-encoded the same integer as
an integer type, you should get the same leading zero in the output.

It sounds like you want to have the integer encoding, but as an octet
or bit string. I think one approach here that would be easier (or at
least seems so to me) would be, rather than parsing the cert twice,
encoding back as an integer but tagging it how you need it:

MemoryVector<byte> serial = cert.serial_number();

pkcs7_encoder.encode(BigInt(&serial[0], serial.size()),
? ? ? ? ? ? ? ? ? ?  OCTET_STRING, UNIVERSAL);

You're right that there should be some easier way to retrieve the
original value, however, especially as it is known there are some
broken implementations out there that do not do the right thing
with integer encodings. In that case, the reencoding technique
would do the wrong thing.

-Jack
-------------- next part --------------
HTML attachment scrubbed and removed

[prev in list] [next in list] [prev in thread] [next in thread]