The way you put it brings one straightforward solution to mind. Solve 1-3 with
a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done.
I do understand that the 4/3 space blowup-of double base64url encoding the JWE
motivates your earlier proposal about nested signing. (See Dick's 10/29/12
message "[jose] signing an existing JWT".) I also understand that if you could
do integrity with the asymmetric signature then the integrity provided by the
JWE itself may be redundant. I don't have a specific proposal on how to do
that.
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dick
Hardt
Sent: Friday, November 02, 2012 8:22 AM
To: [email protected]
Subject: [jose] encrypting AND signing a token
I am trying to figure out how to implement JWT/JWS/JWE to solve a real world
problem.
1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob and then
Alice gives token to Charlie)
2) Alice must be prevented from reading the token. (token needs to be encrypted)
3) Bob and Charlie can share a symmetric key.
I can solve this with JWE.
Now let's add another condition.
4) Charlie wants non-repuditation that Bob created the token.
5) Bob has a private key and a public key
I don't see how to do this using JWE. It seems I have to sign the same token I
had previously with JWS. This seems inefficient since I should be able to
replace the JWE integrity computation done with the symmetric key with the
private key -- but the "alg" parameter is the same in both encrypting and
signing.
Now let's expand this to replacing the symmetric key with a public/private key
pair for encryption. Bob encrypts with Charlies public key and signs with Bob's
private key (we also need to make sure we are not doing naive encryption and
signing here, would be a really useful to specify what needs to be done there).
Now we need to have parameters for both public/private key pairs in the header.
Am I missing something here?
Seems like we can do this if we change the header parameters to specify if they
("alg", "kid", et.c) are for token signing, payload encryption or content key
encryption.
-- Dick
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
