Verify Signature on received PKIMessage fails

Sebastian Hempel <[email protected]> Wed, 04 Dec 2019 15:30:39 +0100
Newsgroups gmane.comp.encryption.bouncy-castle.devel
Message-ID <[email protected]>
Hi,

I'm using BouncyCastle (bc) to communicate with a CMP handler. The=20
source code was first implemented using BouncyCastle 1.51. I want=20
update to the latest version 1.64 of bc. All works well for bc versions=20
including 1.58. Starting with version 1.59 I get an error verifying the=20
signature of the received PKIMessage.

I digged down the source code and found the following reason.

A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for the=20
signature (protection) and a sequence of extra certificates. To=20
validate the signature I take the PKIHeader and the PKIBody of the=20
PKIMessage and use the sequence of these to objects to verify the=20
signature that is contained in the field protection. The verification=20
sometimes succeeds and sometime fails. Rolling back to version 1.58=20
everything works fine.

I found out, that the result of getting the header of the PKIMessage=20
differs from the bytes received from the CMP handler. The field=20
messageTime of the header was changed by bc when getting / encoding the=20
field to DER.

There was a change in the class DERGeneralizedTime in 1.59. The class=20
now contains a method getDERTime to (re-)encode the timestamp. In all=20
versions before 1.59 the byte array was returned directly. All versions=20
starting with 1.59 return the result of the getDERTime method. This=20
method eleminates trailing 0 in the fraction part of the time.

Timestamps directly received from the CMP handler:

20191127144414.20Z
20191127150803.570Z
20191127150848.630Z
20191127151008.290Z
20191127151157.630Z

The method getDERTime returns a different encoding:

20191127144414.2Z
20191127150803.57Z
20191127150848.63Z
20191127151008.29Z
20191127151157.63Z

When calculating the hash for the "new" timestamp there will be no=20
change to get the same value as using the "original" timestamps.

Is this behaviour expected? Is there a way to get the original encoding=20
of the header / messageTime to calculate the hash?

Best regards
Sebastian
--
Sebastian Hempel
Veilchenweg 4 =B7 95195 R=F6slau =B7 Germany
eMail: [email protected]
GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7 B49F


=