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 =