Re: [jose] encrypting AND signing a token

[<[e-mail]>]

A OpenID Connect self-issued token is a signed and then encrypted id_token using JWS then JWE.
Because the audience is part of the id_token the re-encryption issue is not valid in this case.
The signed-and-encrypted JWT is then transported to the RP as a URL fragment.

I have not hit any url length limits on Android but saving some bytes through a combined signend-and-encrypted-format would be good.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dick Hardt
Sent: Sunday, November 04, 2012 8:56 PM
To: Jim Schaad
Cc: 'Mike Jones'; [e-mail]; 'Dick Hardt'
Subject: Re: [jose] encrypting AND signing a token

Thanks Jim. An interesting historical reference. 

In my use case, who signed or who the token is for is not a secret. The payload needs to be kept a secret.

Does no one sign and encrypt SAML tokens?
Is this not a common use case?

If it does need to be solved, it would seem to me that a standards body would be the place to have lots of eyes look at how to sign and encrypt a token so that people do not do naive sign and encrypt.

Q: does anyone else need to sign and encrypt?

-- Dick

On Nov 4, 2012, at 10:24 AM, "Jim Schaad" <[e-mail]> wrote:

> <personal>
> 
> I would note that the original PKCS#7 specifications had a mode that 
> provided a similar sign and encrypt as a single operation mode.  When 
> the
> PKCS#7 specifications where adopted by the IETF as part of the CMS 
> work, this mode was discussed and very deliberately dropped because of 
> numerous security problems that had been found.  These included (but 
> are not limited
> to) the fact that it was signed or who signed it was sometimes a 
> security leak.  Also there were attacks where the signed and encrypted 
> mode could be converted to just an encrypted mode.
> 
> I would think that there would be a need for a very detailed security 
> analysis that we are not prepared to do in order to support a signed 
> and encrypted mode.
> 
> Jim
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf 
>> Of Dick Hardt
>> Sent: Friday, November 02, 2012 12:30 PM
>> To: Mike Jones
>> Cc: [e-mail]
>> Subject: Re: [jose] encrypting AND signing a token
>> 
>> Not only is my original token increasing in size by 4/3, I am also 
>> adding another header, payload and signature.
>> 
>> One of the objectives of JWT was to enabled compact tokens. It would 
>> seem that we should be able to support both signing and encryption of 
>> the same token.
>> 
>> All the encryption use cases I can think of involving asymmetric keys
> would
>> also require signing with the senders private key.
>> 
>> My suggestion is to be explicit in what the algorithm etc. is used for:
>> 
>> Rather than "alg" and "enc", we have:
>> 
>> "algs" - algorithm for token signing
>> "algk" - algorithm for content management key encryption "alge" -
> algorithm
>> for payload encryption
>> 
>> Similiarly,
>> 
>> "kids" - key id for signing
>> "kidk" - key id for content managment key encryption
>> 
>> We could probably make these three or even two letter codes if you 
>> want to save a couple bytes.
>> 
>> -- Dick
>> 
>> On Nov 2, 2012, at 8:46 AM, Mike Jones <[e-mail]>
>> wrote:
>> 
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf 
>>> Of Dick Hardt
>>> Sent: Friday, November 02, 2012 8:22 AM
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose