Re: Verify Signature on received PKIMessage fails

--=-L8rr2lNHnKDvJQjkTUU+
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Thanks for the awnser.

I tried your alternative solution to verify the signature. But this=20
solution also fails on validating responses with a trailing 0 in=20
GeneralizedTime entries. I think the reason for this is, that the=20
method toDLObject in the class ASN1GeneralizedTime also returns a=20
DERGEneralizedTime.

Do you have any links to a document, that describes the conventions /=20
rules howto DER encode a generalized time? I would like to talk to the=20
producer of the CMP handler. It would be easier to give him a kind of=20
refrence about the problen then saying, bouncy castle does not like his=20
encoded PKIMessage. ;-)

Best regards
Sebastian

Am Do, Dez 5, 2019 at 10:12 schrieb David Hook <dgh-rTAZ0PM/[email protected]>:
>=20
> Yes, this would be expected, the signatures in the failing cases are=20
> not being properly calculated.
>=20
> Assuming you can't get whoever is generating these to mend their=20
> ways, you could provide an alternate verify method which read=20
> something like:
>=20
> private boolean verifySignature(byte[] signature, ContentVerifier=20
> verifier)
>     throws IOException
> {
>     ASN1EncodableVector v =3D new ASN1EncodableVector();
>=20
>     v.add(pkiMessage.getHeader());
>     v.add(pkiMessage.getBody());
>=20
>     OutputStream sOut =3D verifier.getOutputStream();
>=20
>     sOut.write(new DERSequence(v).getEncoded(ASN1Encoding.DL));
>=20
>     sOut.close();
>=20
>     return verifier.verify(signature);
> }
>=20
> If I have understood correctly that should work. Note I would still=20
> not make this the default - it would be better if the faulty=20
> signatures were corrected.
>=20
> Regards,
>=20
> David
> On 5/12/19 1:30 am, Sebastian Hempel wrote:
>> Hi,
>>=20
>>  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=20
>> versions including 1.58. Starting with version 1.59 I get an error=20
>> verifying the signature of the received PKIMessage.
>>=20
>>  I digged down the source code and found the following reason.
>>=20
>>  A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for=20
>> the 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=20
>> verification sometimes succeeds and sometime fails. Rolling back to=20
>> version 1.58 everything works fine.
>>=20
>>  I found out, that the result of getting the header of the=20
>> PKIMessage differs from the bytes received from the CMP handler. The=20
>> field messageTime of the header was changed by bc when getting /=20
>> encoding the field to DER.
>>=20
>>  There was a change in the class DERGeneralizedTime in 1.59. The=20
>> class now contains a method getDERTime to (re-)encode the timestamp.=20
>> In all versions before 1.59 the byte array was returned directly.=20
>> All versions starting with 1.59 return the result of the getDERTime=20
>> method. This method eleminates trailing 0 in the fraction part of=20
>> the time.
>>=20
>>  Timestamps directly received from the CMP handler:
>>=20
>>  20191127144414.20Z
>>  20191127150803.570Z
>>  20191127150848.630Z
>>  20191127151008.290Z
>>  20191127151157.630Z
>>=20
>>  The method getDERTime returns a different encoding:
>>=20
>>  20191127144414.2Z
>>  20191127150803.57Z
>>  20191127150848.63Z
>>  20191127151008.29Z
>>  20191127151157.63Z
>>=20
>>  When calculating the hash for the "new" timestamp there will be no=20
>> change to get the same value as using the "original" timestamps.
>>=20
>>  Is this behaviour expected? Is there a way to get the original=20
>> encoding of the header / messageTime to calculate the hash?
>>=20
>>  Best regards
>>  Sebastian
>>  --
>>  Sebastian Hempel
>>  Veilchenweg 4 =B7 95195 R=F6slau =B7 Germany
>>  eMail: [email protected]=20
>> <mailto:[email protected]>
>>  GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7 B49F
>>=20
>>=20
>>=20
>>=20
>>=20
>=20

=

--=-L8rr2lNHnKDvJQjkTUU+
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<div id=3D"geary-body" dir=3D"auto"><div>Thanks for the awnser.</div><div><=
br></div><div>I tried your alternative solution to verify the signature. Bu=
t this solution also fails on validating responses with a trailing 0 in Gen=
eralizedTime entries. I think the reason for this is, that the method toDLO=
bject in the class ASN1GeneralizedTime also returns a DERGEneralizedTime.</=
div><div><br></div><div>Do you have any links to a document, that describes=
 the conventions / rules howto DER encode a generalized time? I would like =
to talk to the producer of the CMP handler. It would be easier to give him =
a kind of refrence about the problen then saying, bouncy castle does not li=
ke his encoded PKIMessage. ;-)</div><div><br></div><div>Best regards</div><=
div>Sebastian</div></div><div id=3D"geary-quote" dir=3D"auto"><br>Am Do, De=
z 5, 2019 at 10:12 schrieb David Hook &lt;dgh-rTAZ0PM/[email protected]&gt;:<br><b=
lockquote type=3D"cite">
 =20
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
 =20
 =20
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">Yes, this would be expected, the
      signatures in the failing cases are not being properly calculated.</d=
iv>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">Assuming you can't get whoever is
      generating these to mend their ways, you could provide an
      alternate verify method which read something like:</div>
    <div class=3D"moz-cite-prefix"><br>
    </div>
    <div class=3D"moz-cite-prefix">
      <pre style=3D"background-color:#ffffff;color:#000000;font-family:'Dej=
aVu Sans Mono';font-size:11.3pt;"><span style=3D"color:#000080;font-weight:=
bold;">private boolean </span>verifySignature(<span style=3D"color:#000080;=
font-weight:bold;">byte</span>[] signature, ContentVerifier verifier)
    <span style=3D"color:#000080;font-weight:bold;">throws </span>IOExcepti=
on
{
    ASN1EncodableVector v =3D <span style=3D"color:#000080;font-weight:bold=
;">new </span>ASN1EncodableVector();

    v.add(<span style=3D"color:#660e7a;font-weight:bold;">pkiMessage</span>=
.getHeader());
    v.add(<span style=3D"color:#660e7a;font-weight:bold;">pkiMessage</span>=
.getBody());

    OutputStream sOut =3D verifier.getOutputStream();

    sOut.write(<span style=3D"color:#000080;font-weight:bold;">new </span>D=
ERSequence(v).getEncoded(ASN1Encoding.<span style=3D"color:#660e7a;font-wei=
ght:bold;font-style:italic;">DL</span>));

    sOut.close();

    <span style=3D"color:#000080;font-weight:bold;">return </span>verifier.=
verify(signature);
}

If I have understood correctly that should work. Note I would still not mak=
e this the default - it would be better if the faulty signatures were corre=
cted.

Regards,

David
</pre>
    </div>
    <div class=3D"moz-cite-prefix">On 5/12/19 1:30 am, Sebastian Hempel
      wrote:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:1575469839.68491.6@hempel-roeslau=
.de">Hi,
      <br>
      <br>
      I'm using BouncyCastle (bc) to communicate with a CMP handler. The
      source code was first implemented using BouncyCastle 1.51. I want
      update to the latest version 1.64 of bc. All works well for bc
      versions including 1.58. Starting with version 1.59 I get an error
      verifying the signature of the received PKIMessage.
      <br>
      <br>
      I digged down the source code and found the following reason.
      <br>
      <br>
      A PKIMessage consists of a PKIHeader, PKIBody, a DERBitString for
      the signature (protection) and a sequence of extra certificates.
      To validate the signature I take the PKIHeader and the PKIBody of
      the PKIMessage and use the sequence of these to objects to verify
      the signature that is contained in the field protection. The
      verification sometimes succeeds and sometime fails. Rolling back
      to version 1.58 everything works fine.
      <br>
      <br>
      I found out, that the result of getting the header of the
      PKIMessage differs from the bytes received from the CMP handler.
      The field messageTime of the header was changed by bc when getting
      / encoding the field to DER.
      <br>
      <br>
      There was a change in the class DERGeneralizedTime in 1.59. The
      class now contains a method getDERTime to (re-)encode the
      timestamp. In all versions before 1.59 the byte array was returned
      directly. All versions starting with 1.59 return the result of the
      getDERTime method. This method eleminates trailing 0 in the
      fraction part of the time.
      <br>
      <br>
      Timestamps directly received from the CMP handler:
      <br>
      <br>
      20191127144414.20Z
      <br>
      20191127150803.570Z
      <br>
      20191127150848.630Z
      <br>
      20191127151008.290Z
      <br>
      20191127151157.630Z
      <br>
      <br>
      The method getDERTime returns a different encoding:
      <br>
      <br>
      20191127144414.2Z
      <br>
      20191127150803.57Z
      <br>
      20191127150848.63Z
      <br>
      20191127151008.29Z
      <br>
      20191127151157.63Z
      <br>
      <br>
      When calculating the hash for the "new" timestamp there will be no
      change to get the same value as using the "original" timestamps.
      <br>
      <br>
      Is this behaviour expected? Is there a way to get the original
      encoding of the header / messageTime to calculate the hash?
      <br>
      <br>
      Best regards
      <br>
      Sebastian
      <br>
      --
      <br>
      Sebastian Hempel
      <br>
      Veilchenweg 4 =B7 95195 R=F6slau =B7 Germany
      <br>
      eMail: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:sebastian=
@hempel-roeslau.de">[email protected]</a>
      <br>
      GnuPG Fingerprint: 9396 67A0 D3F3 6EBB BD7C 783D 34D8 65FE 9EB7
      B49F
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    <p><br>
    </p>
 =20

</blockquote></div>=

--=-L8rr2lNHnKDvJQjkTUU+--