JWT x5c Header seems to be invalid

[c2bo]

The x5c JOSE header of the Request Object JWT seems to be malformed:

eudi-srv-web-verifier-endpoint-23220-4-kt/src/main/kotlin/eu/europa/ec/eudi/verifier/endpoint/VerifierContext.kt

Lines 357 to 359 in 665b69b

	private fun List<X509Certificate>.toBase64PEMEncoded(): List<Base64> =
	this.map { X509CertUtils.toPEMString(it) }.map { Base64.encode(it) }

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?

[dzarras]

Dear @c2bo,

Thanks for reporting this. We are currently actively investigating it, and will keep you posted.

Kind regards.

[dzarras]

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.

[babisRoutis]

@dzarras We need to double check the swift implementation

[dzarras]

Dear @c2bo v0.1.1 of Verifier Endpoint has been released. This new version contains the fix for the bug you reported and is already deployed.

Thanks again for reporting this.