Wrapping my head around JWE and the key management modes.
The point of JWE is to prevent third parties to see/change the token. Only the token issuer and resource server should be able to use it. (Is this correct?)
To encrypt the token's payload, we need to generate CEK (Content Encryption Key). This key is provided to the symmetric algorithm specified inside "enc" JOSE field.
According to https://tools.ietf.org/html/rfc7516, we have 5 ways to get a CEK.
- Key Encryption. CEK is randomly generated, payload encrypted using CEK, CEK encrypted using an asymmetric algorithm-public key - according to "auth" JOSE field, and embedded into the token.
The resource server can discover-deduce the corresponding private key and use the asymmetric algorithm to decipher CEK.
The resource server can discover the corresponding public key in many ways. One of them is jkw in JOSE header. jkw represents the the corresponding public key.
- Key Wrapping. CEK is randomly generated, payload encrypted using CEK, CEK encrypted using a symmetric algorithm, and embedded into the token.
How can the resource server decipher CEK in this case?
- Direct key agreement. CEK is decided based upon a key agreement algorithm.
Do in this case the issuer and the resource sever work together to get CEK first? Do they maintain a session for a while until the CEK is generated? Is this out of specification?
- Key agreement with key wrapping. CEK is randomly generated.
Why do we mention key agreement then?
- Direct encryption. CEK exchanged out-of-band.
Thanks for any feedback.
question from:
https://stackoverflow.com/questions/65895091/jwe-and-the-key-management-modes 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…