Hi Dick, you're right - after actually reading the paper :-), I agree that if you have both sender and receiver in your payload, the order (of encrypting and signing) doesn't seem to matter.
I'm still hesitant, though, to optimize for the encryption use case now (even though I do believe it will be important down the road). If I understand correctly, then the envelope would remain unencrypted. What goes in there? key_id? audience? issuer? timestamp? Do we know whether those things can always remain unencrypted for the use cases we (vaguely) envision? Rather than guessing what would remain unencrypted, and what would be encrypted (which I would have to decide today by specifying what goes into the envelope and what doesn't), I think we should just spec out the unencrypted version today, and spec out the encrypted version later when we get to that bridge, taking care of the issues you brought up, like not double-base64-encoding, etc. Dirk. On Fri, Jul 9, 2010 at 4:45 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > 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 <dick.ha...@gmail.com> 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<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>, >> SWT <http://groups.google.com/group/WRAP-WG/files>, and (even the name >> from) JSON Web >> Tokens<https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#> >> . >> >> 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> >> >> 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<http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures>to >> implement this as a proof-of-concept. >> >> Thoughts? Comments? >> >> Dirk. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
