JWEHeader.Builder.parsedBase64URL enables creation of inconsistent JWEHeaders

[alokmenghrajani]

Hi,

If you have code that looks like this:

JWEHeader header = new JWEHeader.Builder(JWEAlgorithm.DIR, EncryptionMethod.A128GCM)
        .customParam("foo", "bar")
        .parsedBase64URL("some string")
        .build();

and if this header object then flows into a JWEDecrypter, some parts of the code will use the parameters set explicitly (e.g. read the alg as DIR, etc.) but other parts of the code will use the parsedBase64URL (e.g. when validating AAD).

This inconsistency can lead to bugs. It would probably be preferable to either allow setting fields explicitly or setting the parsedBase64URL, but not both.

[Vladimir Dzhuvinov]

Good catch, thank you! Will see that this gets fixed in the next release.

[alokmenghrajani]

It turns out having this quirk is useful in the following scenario:

When handling RSA messages, we want to manually provide the CEK (because the host which has the ability to decrypt the CEK isn't the same as the one processing the JWE payload). When you address this issue, would you be able to provide a decrypt method in RSADecrypter which takes the decryptedKey?

[Vladimir Dzhuvinov]

I was looking at the code the other day, fixing this issue will probably require a bit of refactoring. The "base64url" is passed along at construction time to ensure digital signatures / HMAC over the JWE header can always be recomputed. Just comes to mind that perhaps making parsedBase64URL private is the correct solution here, but I need to check a few more things.

As for adding an option to pass the CEK directly, could you open a separate ticket?