Brian, I was able to finally get a JWT verified with the
QC3VerifySignature api. I'll do a longer writeup for others who will read
this and try it, because I also needed a ptf for our test box to use this
api with the KEYD0600 format.
I believe you are close. Take a look at your job log to see how many
CPF9DCE "A data length is not valid" are being thrown. You can actually
have multiples, in which case you may have a couple of issues. As you
suspected, this error isn't thrown as the message details suggest (The
length has to be 0 or greater) It can be thrown if there is a length that
doesn't make sense.
Parameters 1 and 2 are the signature and the signature length. Lets say
you have a JWT of ABC.DEF.GHIÂ Â ABC would be the header, DEF would be the
payload, and GHI would be the signature. Take the signature, and Base64
decode it. That will reduce the signature length from 340 something down
to 256, which is the length it should be for an RS256 signed JWT. If the
length of the decoded string is not 256, something isn't correct
somewhere. The signature length should match the modulus of the public
key, and for RS256 signed JWT's the modulus is 256 bytes.Â
And although we translate the data to verify and the pem into ascii for
this api, DO NOT translate this signature to ascii. I believe the api is
automatically doing this under the covers, something I discovered the
QC3CalculateSIgnature was also doing. (When calculating the signature,
the signature is being returned in ebcdic even though it had to be
calculated into ascii as all the parms are sent in ascii. )
As far as the data to verify ( parms 3 & 4 ), that will be the Base64
Header plus the period plus the base64 payload. So for a JWT that is
ABC.DEF.GHI, the data to verify is ABC.DEF DO NOT base 64 decode this, but
DO Translate this base64 header period payload string into ascii from
ebcdic. This becomes parm3 , and the length of this string is parm4.
Also, your stored pem should have LineFeed's that separate the records, as
the IBMi crypto requires the line feeds. (This is different from JWT.IO's
site, where if you use it to test verify, it wants the linefeeds removed)
. It should not have carriage returns. If it does, the CR's need to be
removed. I get my pem's (certificates/public keys) straight from google.Â
Their keys are sent in a json object, therefore the linefeeds are escaped
for encoding, and show up as \n in EBCDIC. So I simply scan and replace
every instance of \n with x'25'. Then I convert this pem into ascii and
store it in a file where I can access it by google's key id. By storing it
in ascii, I don't have to perform the pem translation to ascii each time
I call the api, as its already done and stored in ascii.
Michael Catalani
Director, Web Development
3813 Green Hills Village Drive | Nashville, TN 37215
O: 615-844-2883
[1]MCatalani@xxxxxxxxxxxxxx
[2]acceptance.com
 This message and any attachments are intended only for the use of the
person(s) or entity to which it is addressed and may contain information
that is privileged and/or confidential to First Acceptance Corporation. If
the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination or other use of this communication is strictly prohibited.
If you have received this communication in error, notify the sender
immediately by return email and delete the message and any attachments
from your system.
Acceptance Insurance is a registered trademark of First Acceptance
Corporation. All rights reserved. © 2021.
References
Visible links
1. mailto:MCatalani@xxxxxxxxxxxxxx
2.
http://acceptance.com/
midrange.com
