sign data and append certificate VS sign data and certificate

Question

I am currently writing my masters thesis in which I need to develop a licensing module for an application.

The license itself is a JSON Web Token which is signed using a RSA private key.

Since we have the requirement that resellers should also be able to create and sign valid licenses I thought about using a PKI where my company owns the root CA and creates an intermediate certificate for each reseller (so that they can sign their licenses). The root certificate will be part of the final binary ("hiding" the root certificate in that binary is a totally different story). In order for the application to verify the license it needs to check the license's signature and needs to verify the whole certificate chain - that means that the certificate chain (except the root certificate of course) needs to be part of the license.

To my actual question: Should I

1. only sign the JSON Web Token and then append the certificate chain to the license or
2. include the certificate chain into the JSON Web Token and then sign everything altogether?

I have read through some articles that say that one should not hash secrets / through some articles that discuss about MAC-then-encrypt vs encrypt-then-MAC, but none of them can be applied to my problem (since there is neither a secret, nor an encryption involved).

Even if it makes no difference whether I sign only the JWT or the combination of both (JWT + certificate chain) I need to provide some arguments that support and explain the final decision.

Answer 1

Assuming you're using standard PKI certificate standards rather than rolling your own approach there's not really a security benefit to including the certificate chain in the JWT that's covered by the signature.

Each (non-root) certificate is signed by the issuing certificate. So it's already covered by a signature that traces back to your root certificate. Signing it again within the JWT doesn't provide any additional protections.

I also can't see any particular security risk with including the certificate chain within the signed portion of the JWT. A signature exists to prove the authenticity of a known message. So has to be secure when the signed text is known. Including a known certificate chain does not therefore introduce any particular risks.

So really you need to drive this decision from other application design considerations.

Including the certificate chain in the JWT has one advantage I can see which is that you can parse the message using a standard library rather than having to pre-process it.

However in most scenarios that would be out-weighed significantly by the downsides of including the certitificate chain in the JWT which are:

• You're signing a lot more content than you need to so are wasting a bit of CPU
• You can't seperate the token from the certificate chain. That's likely to reduce the flexibility in the application design.

EOver time you may want to be able to just deal with the license in parts of the application where you know the certificate chain has already been processed, or allow it to be resolved dynamically. By keeping the certificate chain out of the signed JWT you can more easily split the two concerns apart to be dealt with by different parts of the application.

This wil also help if you wanted to move to encrypting the token in future rather than just signing it. By keeping the certificate chain seperate you can work with it before decrypting and checking the token which will make it easier to setup the validation routine.