[Openid-specs-ab] JWT encryption

Nat Sakimura sakimura at gmail.com
Fri Jan 13 00:32:06 UTC 2012

See also the archive of JOSE list:


There has been no push back. In fact, Eric et al. also agreed.


So the assumption would be to go ahead with CMK in header and generating
CIK and CEK, mandating integrity check for CBC mode.

It is just that the editors need to capture those into the next draft.


On Fri, Jan 13, 2012 at 7:55 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> This is really a discussion for the IETF JOSE list.
> Having a content master key allows for key rotation of the bulk key.
> It also keeps Symmetric and asymmetric more consistent.
> I understand the size issue.
> Perhaps we could argue for a additional mode without the key wrap and using
> the shared secret directly
> It is a space vs security optimization.
> I think we should take that to the JOSE list.
> John B.
> On 2012-01-12, at 7:27 PM, Dirk Balfanz wrote:
> On Thu, Jan 12, 2012 at 1:49 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> The plan is to have a encryption with integrity mode that doesn't require
>> GCM.
>> You create a content master key and key wrap that (Symmetric or
>> Asymmetric).  That key is used with a KDF to crate 2 keys,  a content
>> encryption key and a integrity key.
>> The content is AES CBC 128 encrypted (as an example).  Then a HMAC is
>> calculated over the encrypted body using the integrity key.
> This sounds good. One question: if the key I want to use to encrypt-and-sign
> is already a, say, 128-bit symmetric key, then creating another 128-bit
> "master" key (which needs to be wrapped) and KDF-ing the signer and
> encrypter from that seems like overkill. Why not just KDF the signer and
> encrypter directly from my original key? It makes the spec more complex (in
> some cases you can skip the wrapping of the master key, and some you can't),
> but shipping an extra key around when you don't need to is no fun...
> Dirk.
>> To decrypt the process is reversed.
>> Assuming that you are using symmetric keys the one composite operation
>> gets you encryption integrity and verification of the sender.
>> This will be added to a upcoming draft of JOSE (if there is support).
>> The fist JOSE draft will not have normative changes from the existing input
>> specs.
>> If you want to use asymmetric keys you will still need to do a separate
>> signing step.  It can be inside or outside the encryption depending on use
>> case.
>> John B.
>> On 2012-01-12, at 6:29 PM, Breno de Medeiros wrote:
>> > This is feedback related to the JWT Encryption/JWS specs. I am
>> > submitting this here because we're reviewing the whole stack. Independently
>> > of the Connect implementation, we are working on a different project that
>> > uses JWT encryption.
>> >
>> > In this first usage of JWT encryption, we need integrity-protected
>> > encrypted payloads. We do not need non-repudiation. The underlying libraries
>> > do not have support for AES-GCM. We don't expect the latter reality to
>> > change for a number of years since the clients have a slow update cycle.
>> >
>> > The JWT Encryption/JWS spec do appear to support this use case. Note
>> > that to have integrity encrypted data, one needs to perform
>> > encryption-then-authentication, since that is the correct order to compose
>> > these primitives. So my first observation is that this security
>> > recommendation in the JWT encryption spec is factually incorrect when
>> > referring to symmetric authentication schemes as opposed to public key
>> > signatures:
>> >
>> > "This document does not specify a combination signed and encrypted
>> >   mode.  However, because the contents of a message can be arbitrary,
>> >   encryption and data origin authentication can be provided by
>> >   recursively encapsulating multiple JWE and JWS messages.  In general,
>> >   senders SHOULD sign the message and then encrypt the result (thus
>> >   encrypting the signature).  This prevents attacks in which the
>> >   signature is stripped, leaving just an encrypted message, as well as
>> >   providing privacy for the signer."
>> >
>> > In addition, the JWT Encryption/JWS recommends Sign-then-encrypt, which
>> > provides confidentiality of signed data, but does not provide integrity of
>> > the encrypted data. So in some scenarios you could attack the encryption
>> > layer by sending random data and forcing it to decrypt blindly. The
>> > signature verification step performed after the decryption may be too late.
>> > Again, to protect the encryption layer, one should encrypt then
>> > sign/authenticate.  So if one wants to have both confidentiality and
>> > non-repudiation which the JWT/JWS specs are designed to support) and AES-GCM
>> > is not available (as the case in the next few years depending on which
>> > environment you're targeting), the only way to use the JWT/JWS specs
>> > securely is to sign, then encrypt,
>> > then sign (or authenticate) again. Which is terribly inefficient.
>> >
>> > In other words, in our security review, the only usable mode for JWT
>> > encryption defined today is AES-GCM. Which is not generally available.
>> >
>> > Is that the desirable state of things? Because if so, we plan to define
>> > some other way to use encryption with JWT instead.
>> >
>> > --
>> > --Breno
>> >
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > Openid-specs-ab at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

Nat Sakimura (=nat)
Chairman, OpenID Foundation

More information about the Openid-specs-ab mailing list