Closed c2bo closed 5 months ago
Dear @c2bo,
Thanks for reporting this. We are currently actively investigating it, and will keep you posted.
Kind regards.
Dear @c2bo,
We acknowledge the issue. It is indeed a bug. Even though the client implementation is correct, we didn't detect this issue earlier due to the following:
When trying to parse a X509 certificate you end up in sun.security.provider.X509Factory.engineGenerateCertificate(InputStream)
.
This method uses internally sun.security.provider.X509Factory.readOneBlock(InputStream)
.
The javadoc of the latter reads:
Returns an ASN.1 SEQUENCE from a stream, which might be a BER-encoded binary block or a PEM-style BASE64-encoded ASCII data. In the latter case, it's de-BASE64'ed before return. After the reading, the input stream pointer is after the BER block, or after the newline character after the -----END SOMETHING----- line.
In effect this method is able to decode both base64 encoded DERs and base64 encoded PEMs.
Thanks again for reporting this.
@dzarras We need to double check the swift implementation
The x5c JOSE header of the Request Object JWT seems to be malformed: https://github.com/eu-digital-identity-wallet/eudi-srv-web-verifier-endpoint-23220-4-kt/blob/665b69b0c58f19f4ec022792fab49d412e8818ec/src/main/kotlin/eu/europa/ec/eudi/verifier/endpoint/VerifierContext.kt#L357-L359
generates a list of base64 encoded PEM, whereas the RFC defines it as a list of base64 encoded DER (https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.6). Every Request Object JWT will have an invalid x5c header and can't be verified with default JWT/JAR implementations.
This issue is probably present in the client implementation as well?