Hi Dirk
Responding to this now that you are back.
From:
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
(which is the whitepaper talking contrasting "encrypt-then-sign" and
"sign-then-encrypt")
The simple solution seems to be to include both sender and recipient in the
plain text.
At first glance your proposal of:
encrypted_token = encryption(JSON_Token) || "." || envelope
envelope = base64(JSON(everything you need to know to decrypt))
This seems to work - I am unsure where the signature is. Ideally you encrypt
the binary of the signature rather than the base64url version.
Ideally the JSON_Token would also have an envelope so that the same code could
look at the envelope to decide what to do with it regardless of if it was
encrypted or not.
Perhaps the first string would always be an envelope that would contain
everything to either decrypt or verify the payload?
-- Dick
On 2010-06-22, at 10:57 PM, Dirk Balfanz wrote:
> Hi Dick,
>
> interesting point about encrypted payloads.
>
> People more cryptographically-inclined than me might want to chime in, but I
> do seem to remember that there is a "correct" choice among the
> "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search
> seems to suggest that the latter is what you want:
> https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06/30/837.aspx.
>
>
> So I would suggest that encrypted payloads are implemented as an encryption
> of a JSON Token, as in:
>
> encrypted_token = encryption(JSON_Token) || "." || envelope
> envelope = base64(JSON(everything you need to know to decrypt))
>
> What do you think?
>
> Dirk.
>
>
> On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <[email protected]> wrote:
> Thanks for writing this up Dirk.
>
> I would suggest that the token be:
>
> payload "." envelope "." signature
>
> This enables the payload to be encrypted and independent from the envelope.
>
> Token signing, verification, encryption and decryption code can then be
> generic and not understand the payload of the token.
>
> I would only include issuer, key_id and alg in the envelope.
>
> Audience, scope, nonce, and validation time information etc. would be in the
> payload.
>
> -- Dick
>
> On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote:
>
>> Hi guys,
>>
>> I think I owe the list a proposal for signatures.
>>
>> I wrote something down that liberally borrows ideas from Magic Signatures,
>> SWT, and (even the name from) JSON Web Tokens.
>>
>> Here is a short document (called "JSON Tokens") that just explains how to
>> sign something and verify the signature:
>> http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4
>>
>> Here is an extension of JSON Tokens that can be used for signed OAuth tokens:
>> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU
>>
>> Here is a different extension of JSON Tokens that can be used for 2-legged
>> flows. The idea is that this could be used as a drop-in replacement for SAML
>> assertions in the OAuth2 assertion flow:
>> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
>>
>> I also have started to write some code to implement this as a
>> proof-of-concept.
>>
>> Thoughts? Comments?
>>
>> Dirk.
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
