Subject: Re: [OAUTH-WG] proposal for signatures

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 19:49:00 -0700

Can we get an updated document based on the feedback received?

EHL

On 6/21/10 12:04 AM, "Dirk Balfanz" <[email-masked]> 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.

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 9 Jul 2010 13:39:01 -0700

>  Can we get an updated document based on the feedback received?

Sure - I just got back from my vacation. I'll read through the thread and
update the docs.

Cheers,

Dirk.

> 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 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:
>
> 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.
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Jul 2010 16:23:01 -0700

I don't understand. You are Allowed time off spec work during vacation? Hmm. (-:

EHL

On Jul 9, 2010, at 16:39, Dirk Balfanz <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 7, 2010 at 7:49 PM, Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Can we get an updated document based on the feedback received?

Sure - I just got back from my vacation. I'll read through the thread and update the docs.

Cheers,

Dirk.

EHL

On 6/21/10 12:04 AM, "Dirk Balfanz" <<http://[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

</>  </> Hi guys,

I wrote something down that liberally borrows ideas from Magic Signatures <<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html> , SWT <<http://groups.google.com/group/WRAP-WG/files>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#>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>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>
<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>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>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.

---

From: Dick Hardt <[email-masked]>
Date: Fri, 9 Jul 2010 16:45:21 -0700

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-masked]> 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 wrote something down that liberally borrows ideas from Magic Signatures, SWT, and (even the name from) JSON Web Tokens. 
>> 
>> Here is an extension of JSON Tokens that can be used for signed OAuth tokens:
>> I also have started to write some code to implement this as a proof-of-concept. 
>> 
>> Thoughts? Comments?
>> 
>> Dirk.
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
>

---

From: Paul Tarjan <[email-masked]>
Date: Sat, 10 Jul 2010 16:58:46 +0000

Hi OAuthers,

First of all, I think I should introduce myself. I work at Facebook on the Platform team (anything not facebook.com<http://facebook.com>). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth applications and libraries, both at Yahoo and in my spare time.

For Facebook apps we're going to use your signature scheme with the following changes:

* the signature comes before the payload
* we used the key 'algorithm' instead of 'alg' and 'expires' instead of 'not_before'
* we aren't sending any keys except algorithm, expires, and oauth_token (since we're a special use case)
* we named the parameter signed_request because it is the signed part of a request

We would love if you could adopt those changes. Then you'd have a real world implementation out the door already :) We plan on launching July 20.

Paul

Sent from my iPhone

On Jul 9, 2010, at 1:39 PM, "Dirk Balfanz" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Dirk.

EHL

</>  </> Hi guys,

Thoughts? Comments?

Dirk.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Sat, 10 Jul 2010 11:00:35 -0700

On 2010-07-10, at 9:58 AM, Paul Tarjan wrote:

> Hi OAuthers,
> 
> First of all, I think I should introduce myself. I work at Facebook on the Platform team (anything not facebook.com). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth applications and libraries, both at Yahoo and in my spare time.  
> 

I would hope you would think it is "our" signature scheme rather than "your" signature scheme

> * we used the key 'algorithm' instead of 'alg' and 'expires' instead of 'not_before'

Good points to add to the discussion. Perhaps you would articulate why you made those choices?

> * we aren't sending any keys except algorithm, expires, and oauth_token (since we're a special use case)

If you are a special use case, then not sure why there is any point in being a standard.
Assuming you meant "parameters" instead of "keys"? "key" has special meaning when  you are discussing crypto.

> * we named the parameter signed_request because it is the signed part of a request  

Which parameter?

> We would love if you could adopt those changes. Then you'd have a real world implementation out the door already :) We plan on launching July 20. 

Er, we welcome feedback on the standard. Facebook can deploy whatever they want to deploy. An early implementation is useful to see what the issues might be. While possible, it is unlikely what you deploy will be the standard.

> Sent from my iPhone

Thanks for letting us know what device you use.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 10 Jul 2010 11:06:11 -0700

We need to get this into a proper draft (which I understand is on Dirk's list) and do a round of feedback before we promote this to a WG draft. I'm happy to help with editorial work if needed.

Given the wide range of use cases, I think we need to keep this work focused on the use cases driving it, and not try to make it too generic.

EHL

On Jul 10, 2010, at 14:00, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hi OAuthers,

First of all, I think I should introduce myself. I work at Facebook on the Platform team (anything not <http://facebook.com/> facebook.com<http://facebook.com>). Before this I was at Yahoo! doing SearchMonkey (semantic web stuff). I've written a few OAuth applications and libraries, both at Yahoo and in my spare time.

Which parameter?

Paul

Sent from my iPhone

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Sat, 10 Jul 2010 11:48:21 -0700

I agree we don't want to end up like other protocols that were too generic. :)

The use case I am arguing for is sending encrypted tokens. Higher levels of assurance require this and various people brought this up as a requirement when WRAP was presented at IIW 09B.

-- Dick

---

From: David Recordon <[email-masked]>
Date: Sat, 10 Jul 2010 13:21:53 -0700

On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt <[email-masked]> wrote:

> First of all, I think I should introduce myself. I work at Facebook on the
> Platform team (anything not facebook.com). Before this I was at Yahoo!
> doing SearchMonkey (semantic web stuff). I've written a few OAuth
> applications and libraries, both at Yahoo and in my spare time.
>

I think Paul was referring to the proposal Dirk put forward since there
isn't anything which has become part of OAuth yet. ;)

> Good points to add to the discussion. Perhaps you would articulate why you

I think Naitik talked about the signature coming before the payload in this
thread. Through implementations we've found that lsplit is easier in some
languages.

The benefit of using 'alg' is unclear compared to spelling out the word
'algorithm' which adds clarity for developers.

* we aren't sending any keys except algorithm, expires, and oauth_token
> (since we're a special use case)
>
>

Some more background is needed here. We're not currently implementing
signatures for our protected resources, but rather to send some trusted
parameters from the authorization server to the client. We're starting with
a use case entirely on Facebook.com (our canvas applications) and thus have
a different set of security considerations.

There is value in the underlying signature format being the same. Thus
making use of signed JSON – the hard part – even if some of the parameters
within are different.

> meaning when  you are discussing crypto.

Yes.

* we named the parameter signed_request because it is the signed part of a
> request

The context above should be helpful. This would be the parameter name coming
from the AS to the client.

> We would love if you could adopt those changes. Then you'd have a real
> world implementation out the door already :) We plan on launching July 20.
>
>
> Er, we welcome feedback on the standard. Facebook can deploy whatever they
> want to deploy. An early implementation is useful to see what the issues
> might be. While possible, it is unlikely what you deploy will be the
> standard.
>
>
> Paul
>
> Sent from my iPhone
>
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 10 Jul 2010 13:29:29 -0700

On 2010-07-10, at 1:21 PM, David Recordon wrote:

> I think Paul was referring to the proposal Dirk put forward since there isn't anything which has become part of OAuth yet. ;)

The email was addressed to "OAuthers" -- I would hope that Paul would soon consider himself one of those!

> I think Naitik talked about the signature coming before the payload in this thread. Through implementations we've found that lsplit is easier in some languages.

I think having an envelope as the first blob enables a parser to know what to do with the rest of the blobs, and that this trumps the mionor lsplit argument.

> 
> The benefit of using 'alg' is unclear compared to spelling out the word 'algorithm' which adds clarity for developers.

Agree that 'algorithm' is easier to understand and preferable to 'alg'

-- Dick

---

From: David Recordon <[email-masked]>
Date: Sat, 10 Jul 2010 13:42:08 -0700

On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt <[email-masked]> wrote:

> I think having an envelope as the first blob enables a parser to know what
> to do with the rest of the blobs, and that this trumps the mionor lsplit
> argument.
>

And we think that adding an envelope creates unnecessary complexity for both
server and client developers for the signature use cases.

--David

---

From: Dick Hardt <[email-masked]>
Date: Sat, 10 Jul 2010 14:22:31 -0700

On 2010-07-10, at 1:42 PM, David Recordon wrote:

> And we think that adding an envelope creates unnecessary complexity for both server and client developers for the signature use cases.

Obviously anything besides what you need for your use case adds complexity. The question is: are you willing to accept some complexity so that it works for use cases than yours? If not, then perhaps you should just define your own signature mechanism.

I don't see parsing two base64url encoded JSON strings as being that much more complex than parsing one. Repeating one step that then enables extensibility for the future as to how to parse the rest of the token, and enables the same code to look at encrypted tokens in addition to tokens that have only been signed. The alternative is the client and server have to know ahead of time what is being sent and can't mix them -- that adds complexity later on.

-- Dick

---

From: David Recordon <[email-masked]>
Date: Sat, 10 Jul 2010 14:49:57 -0700

On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt <[email-masked]> wrote:

> Obviously anything besides what you need for your use case adds complexity.
> The question is: are you willing to accept some complexity so that it works
> for use cases than yours? If not, then perhaps you should just define your
> own signature mechanism.
>

I think that you misunderstood what I was saying. The use case that Paul
described is more limited than the signature use cases for OAuth 2.0. An
envelope is not required for the signature use cases for OAuth 2.0. As you
pointed out later, it could be required for different use cases of
encrypting and signing requests.

--David

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 15 Jul 2010 17:29:36 -0700

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 <[email-masked]> wrote:

> 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
>
> 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
> .
>
>> Token signing, verification, encryption and decryption code can then be
>> generic and not understand the payload of the token.
>>
>> 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#>
>> .
>>
>> tokens:<http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU>
>>
>> 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.
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 15 Jul 2010 21:19:32 -0700

On 2010-07-15, at 5:29 PM, Dirk Balfanz wrote:

> 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?

The envelope contains what is needed to do the crypto, regardless of it being  signature verification or decryption. That would mean algorithm and key_id if used. Issuer would be needed if you need that to determine the key. Audience and issuer should also be in the payload per the paper.

A library looking at the envelope would be able to decrypt the token and check the signature or just check the signature. The idea of the envelope is that the library only needs to look at the envelope to decide what to do. 

Message verification is something implementors get wrong all the time, so the easier we make it for libraries, the more likely there will be good libraries that people can use in different situations.

> 
> 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.

I don't think we need to guess now at all. We don't even have to figure out what needs to be in the envelope to do encryption. I am arguing for an architectural approach of an envelope and a payload rather than just a payload. (or in the case of digital signing, I am arguing for envelope, payload and signature rather than just signature and payload)

This has several benefits:

1) the payload now can be encrypted independant of envelope (encryption inherently means there is a separate envelope -- only signing can take a shortcut and mix envelope data with payload since the payload is clear text)

2) we can use the same libraries in the future for all tokens

3) we have an extensibility model

The benefits seem to outweigh the downside of having two JSON entities instead of just one.

In many ways, this is similar to the header and body in HTTP requests. A separation of transport parameters from payload data has proven useful in many other architectures and protocols.

-- Dick

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 27 Jul 2010 15:58:44 +0900

If we were using PKCS#7 for certs, then why not PKCS#7 the payload as well?

(No - I am not proposing to do it. Doing so with AES-128,192,256 is
prohibitive in some language such as PHP, but just as a point of
discussion to close this.)

On Tue, Jun 22, 2010 at 6:33 PM, Ben Laurie <[email-masked]> wrote:
> On 22 June 2010 02:40, Manger, James H <[email-masked]> wrote:
>> Nat and Ben,
>>
>>
>>
>>>>> In addition to Ben's questions, I have another. For X.509, you seem to
>>
>>>>> be using DER. How do you express the entire certificate chain using
>>
>>>>> DER?
>>
>>>>> (With PEM, you can just concatenate ... )
>>
>>>>
>>
>>>> With DER you can concatenate, too, of course. There's also PKCS#n (for
>>
>>>> some value of n which I forget ... 12?) which allows bundling of cert
>>
>>>> chains.
>>
>>>
>>
>>> That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes
>>> the
>>
>>> private key, though.
>>
>>
>>
>>
>>
>> A *.p7c file can be used to hold any number of certificates. It is a
>> BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS)
>> standard [RFC 5652]. It is the ASN.1 syntax used for S/MIME signed email. If
>> you only want to send certificates, just leaving out the
>> content-to-be-signed, and the signatures.
>
> Ah, thanks, I thought there was something less kludgey than PKCS#12.
>
>>
>>
>>
>> Such a file can hold any number of certificates, including public-key
>> certificates, attribute certificates, or other certificate formats.
>>
>> It can also hold CRLs and other revocation information (including OCSP
>> responses as per draft-turner-additional-cms-ri-choices).
>>
>>
>>
>> CMS/PKCS#7 is better for this purpose than PKCS#12.
>>
>>
>>
>> --
>>
>> James Manger
>>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en