Re: [jose] encrypting AND signing a token

[John Bradley <[e-mail]>]

Probably not:)

On 2012-11-06, at 11:10 AM, "Richard L. Barnes" <[e-mail]> wrote:

> +1
> 
> Can we please stop confusing signing and MAC?
> 
> 
> 
> On Nov 6, 2012, at 10:54 AM, Jim Schaad <[e-mail]> wrote:
> 
>> <personal>
>> 
>> Only if you have a really loose definition of signing - it gives you an
>> integrity check but not origination which is usually implied by the term
>> signing
>> 
>> Jim
>> 
>> 
>>> -----Original Message-----
>>> From: John Bradley [mailto:[e-mail]]
>>> Sent: Tuesday, November 06, 2012 10:50 AM
>>> To: Dick Hardt
>>> Cc: Jim Schaad; 'Mike Jones'; [e-mail]
>>> Subject: Re: [jose] encrypting AND signing a token
>>> 
>>> I should also note that with symmetric keys, the alg option of A128KW with
>>> an enc of A128CBC+HS256 effectively gives you signing and encryption in a
>>> single JWE.
>>> 
>>> That doesn't solve the asymmetric signing case, but may work for some
>>> people .
>>> 
>>> John B.
>>> On 2012-11-06, at 10:37 AM, John Bradley <[e-mail]> wrote:
>>> 
>>>> SAML performs this as separate operations.
>>>> 
>>>> Now in some cases the assertion is signed then encrypted and then the
>>> message signed to deal with the AESCBC padding oracle attack.
>>>> 
>>>> There is non technical issue around the use of qualified signatures in
>> cases
>>> where non repudiation is required.
>>>> Signing a encrypted object has different connotations than signing a
>>> unencrypted one.
>>>> 
>>>> I don't know what the status of a combined operation would be.   It is
>>> probably not relevant to your use case.
>>>> 
>>>> At IETF #83 I presented including ECDH-SS as an encryption option as it
>>> provides sender verification.
>>>> I think that would answer your use case, depending on how you feel about
>>> EC.
>>>> 
>>>> The work group rejected adding that algorithm at the time on the grounds
>>> that it is not used in places where it is supported.
>>>> ECDH-ES is defined and is considered more secure than ECDH-SS mostly
>>> because it is harder to get wrong.
>>>> 
>>>> I am not recommending revisiting the issue, but it would be a way to
>>> address the composite use case.
>>>> 
>>>> Despite being a Canadian I am not shilling for certicom.  Just saying.
>>>> 
>>>> John B.
>>>> On 2012-11-04, at 2:55 PM, Dick Hardt <[e-mail]> wrote:
>>>> 
>>>>> 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
>