Different certificate order in time-stamp token when using new API

Different certificate order in time-stamp token when using new API

Hello everybody,

A user of our software discovered that after upgrading from one version
to an other, suddenly the order of the certificates in the time-stamp
tokens changed. This causes some concerns to them with legacy software.

In BC 1.45 the order of the certificates as seen with an ASN.1 dump was
always the same as the order of the certificates in the CertStore while
in BC 1.54 for some certificates the order was different from what was
in the Store and in fact changing the order of the certificates in the
Store did not influence the order in the encoded output.

After further investigation I found out that this change can most easily
be seen in BC 1.49 which has both the old and new API. When using the
old deprecated method it works (meaning that the order of the CertStore
influence the order of the output) while when using the new method the
order is different for some certificates:
Old deprecated and working:
TimeStampResponseGenerator.generate(TimeStampRequest,BigInteger,Date,String
provider)
New method not working :
TimeStampResponseGenerator.generate(TimeStampRequest,BigInteger,Date)

Looking into the differences of those methods it can be seen that the
tstTokenContenInfo is generated in slightly different ways:
1) In new API the
TimeStampResponseGenerator.generateGrantedResponse(...) does
(TimeStampResponseGenerator.java:317):
tstTokenContentInfo = tokenGenerator.generate(request, serialNumber,
genTime).toCMSSignedData().toASN1Structure();

2) While in the old API TimeStampResponseGenerator.generate(...) does
the following which works (TimeStampResponseGenerator.java:183):
ByteArrayInputStream bIn = new
ByteArrayInputStream(tokenGenerator.generate(request, serialNumber,
genTime, provider).toCMSSignedData().getEncoded());
ASN1InputStream aIn = new ASN1InputStream(bIn);
tstTokenContentInfo = ContentInfo.getInstance(aIn.readObject());

Could it be the extra encoding and parsing in 2) that somehow makes the
order stay?
Could there be a bug in either the old or the new response generator?

Re: Different certificate order in time-stamp token when using new API

Hi,

Okay, is the response being DER encoded after creation? That would
explain what you are seeing.

I think if the object is being written to a DLOutputStream instead of a
DEROutputStream you will get the effect desired. I would be advising
anyone who cares that a SET in ASN.1 is not ordered - so it is a mistake
to rely on ordering in general (although I am aware of at least one
government standard where this is, apparently, not understood).

Regards,

David

On 13/06/17 01:48, Markus Kilås wrote:

> Hello everybody,
>
> A user of our software discovered that after upgrading from one version
> to an other, suddenly the order of the certificates in the time-stamp
> tokens changed. This causes some concerns to them with legacy software.
>
> In BC 1.45 the order of the certificates as seen with an ASN.1 dump was
> always the same as the order of the certificates in the CertStore while
> in BC 1.54 for some certificates the order was different from what was
> in the Store and in fact changing the order of the certificates in the
> Store did not influence the order in the encoded output.
>
> After further investigation I found out that this change can most easily
> be seen in BC 1.49 which has both the old and new API. When using the
> old deprecated method it works (meaning that the order of the CertStore
> influence the order of the output) while when using the new method the
> order is different for some certificates:
> Old deprecated and working:
> TimeStampResponseGenerator.generate(TimeStampRequest,BigInteger,Date,String
> provider)
> New method not working :
> TimeStampResponseGenerator.generate(TimeStampRequest,BigInteger,Date)
>
> Looking into the differences of those methods it can be seen that the
> tstTokenContenInfo is generated in slightly different ways:
> 1) In new API the
> TimeStampResponseGenerator.generateGrantedResponse(...) does
> (TimeStampResponseGenerator.java:317):
> tstTokenContentInfo = tokenGenerator.generate(request, serialNumber,
> genTime).toCMSSignedData().toASN1Structure();
>
> 2) While in the old API TimeStampResponseGenerator.generate(...) does
> the following which works (TimeStampResponseGenerator.java:183):
> ByteArrayInputStream bIn = new
> ByteArrayInputStream(tokenGenerator.generate(request, serialNumber,
> genTime, provider).toCMSSignedData().getEncoded());
> ASN1InputStream aIn = new ASN1InputStream(bIn);
> tstTokenContentInfo = ContentInfo.getInstance(aIn.readObject());
>
> Could it be the extra encoding and parsing in 2) that somehow makes the
> order stay?
> Could there be a bug in either the old or the new response generator?
>

Re: Different certificate order in time-stamp token when using new API

On 06/13/2017 02:15 AM, David Hook wrote:

>
> Hi,
>
> Okay, is the response being DER encoded after creation? That would
> explain what you are seeing.
>
> I think if the object is being written to a DLOutputStream instead of a
> DEROutputStream you will get the effect desired. I would be advising
> anyone who cares that a SET in ASN.1 is not ordered - so it is a mistake
> to rely on ordering in general (although I am aware of at least one
> government standard where this is, apparently, not understood).

Hi David,

Thank you for your response.

All we do with the response afterwards is to call
TimeStampResponse.getEncoded() to get it as a byte array. Maybe that
internally is using a DEROutputStream I haven't been able to track that.

I am not sure if it is the best way of doing it but at least it is
working for us. Do you think it would make sense to include it?

I get your point about the SET not being ordered and I have raised that
issue but some users are still really concerned about the concequences
for legacy sofware...

Best Regards,
Markus
PrimeKey Solutions

>
> Regards,
>
> David
>
> On 13/06/17 01:48, Markus Kilås wrote:
>> Hello everybody,
>>
>> A user of our software discovered that after upgrading from one version
>> to an other, suddenly the order of the certificates in the time-stamp
>> tokens changed. This causes some concerns to them with legacy software.
>>
>> In BC 1.45 the order of the certificates as seen with an ASN.1 dump was
>> always the same as the order of the certificates in the CertStore while
>> in BC 1.54 for some certificates the order was different from what was
>> in the Store and in fact changing the order of the certificates in the
>> Store did not influence the order in the encoded output.
>>
>> After further investigation I found out that this change can most easily
>> be seen in BC 1.49 which has both the old and new API. When using the
>> old deprecated method it works (meaning that the order of the CertStore
>> influence the order of the output) while when using the new method the
>> order is different for some certificates:
>> Old deprecated and working:
>> TimeStampResponseGenerator.generate(TimeStampRequest,BigInteger,Date,String
>> provider)
>> New method not working :
>> TimeStampResponseGenerator.generate(TimeStampRequest,BigInteger,Date)
>>
>> Looking into the differences of those methods it can be seen that the
>> tstTokenContenInfo is generated in slightly different ways:
>> 1) In new API the
>> TimeStampResponseGenerator.generateGrantedResponse(...) does
>> (TimeStampResponseGenerator.java:317):
>> tstTokenContentInfo = tokenGenerator.generate(request, serialNumber,
>> genTime).toCMSSignedData().toASN1Structure();
>>
>> 2) While in the old API TimeStampResponseGenerator.generate(...) does
>> the following which works (TimeStampResponseGenerator.java:183):
>> ByteArrayInputStream bIn = new
>> ByteArrayInputStream(tokenGenerator.generate(request, serialNumber,
>> genTime, provider).toCMSSignedData().getEncoded());
>> ASN1InputStream aIn = new ASN1InputStream(bIn);
>> tstTokenContentInfo = ContentInfo.getInstance(aIn.readObject());
>>
>> Could it be the extra encoding and parsing in 2) that somehow makes the
>> order stay?
>> Could there be a bug in either the old or the new response generator?
>>
>