Re: [jose] encrypting AND signing a token

[<[e-mail]>]

I am using an RP that uses an openid-url scheme to  let the Android App know the openid connect object.
openid://?response_type=id_token&client_id=https://gabunomi.net/seminar/callback.html&request=header.payload.signatur&state=50982a45f0ec1&nonce=50982a45f12ab

The id_token is returned to the RP in a fragment.
https://server/callback.html#id_token=signed-then-encrypted-id_token

I did not test the size limits but it worked for an id_token with claims email, display name and picture url. Inside is a user_jwk with a public key. The corresponding private key is used to sign the id_token. It is unique per RP.

The algs used are RSA1_5 and A256CBC+HS256.

I don't know whether I can name the RP's url here. Maybe its owner wants to do that. The RP is currently moving to another domain. I guess it is public after the move.

Axel

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dick Hardt
Sent: Monday, November 05, 2012 8:47 PM
To: Nennker, Axel
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [jose] encrypting AND signing a token

Thanks Axel. Nice to know the implementation I am working on is not the only one.

Do you know what algorithm is being used for signing and encrypting in deployments? 

The implementation I am working on passes the token using a custom scheme in iOS and Android. I am concerned about the token size, but don't know the limits.

-- Dick

On Nov 5, 2012, at 6:57 AM, <[e-mail]> wrote:

> 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

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