Re: [OAUTH-WG] signatures, v2

[Nat Sakimura <[e-mail]>]

On Wed, Jul 21, 2010 at 8:27 PM, Ben Laurie <[e-mail]> wrote:
> On 16 July 2010 01:43, Dirk Balfanz <[e-mail]> wrote:
>> Hi guys,
>> after reading through the feedback, we did a pass over the OAuth signature
>> proposals.
>> As a reminder, there are three documents:
>> - a 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
>>
>> - an extension of JSON Tokens that can be used for signed OAuth tokens:
>> http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU
>> - a different extension of JSON Tokens that can be used whenever the spec
>> calls for an "assertion":
>> http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
>> (When used in the assertion flow, this last token can also be used to do
>> "2-legged" OAuth)
>>
>> A summary of the (scant) changes:
>> - we spelled out what we mean by RSA-SHA256. Ben Laurie - can you
>> double-check that that sounds good?
>
> Nearly missed this, somehow. Yes, looks good to me. A reference would
> be nice (RFC 3447, for example).

Magic Signatures is using EMSA-PKCS1-v1_5 instead of PSS because it has
wider library supports, I believe. For example, OpenSSL library
interface in PHP
does not seem to support PSS.

>
>> - we decided on unpadded websafe-base64 throughout.
>> - some changes to parameter names.
>> - some small changes I might be forgetting now...
>> As explained in my message to the previous thread, there is still no
>> envelope in there to help with encrypted tokens (b/c we don't understand
>> well enough what the envelopes for encrypted tokens would look like).

Perhaps http://tools.ietf.org/html/draft-sakimura-jsonenc-00 help?

>> One question: What's the deal with having the signature go first? If you can
>> explain to me why that is a good idea, I'm happy to oblige.

With Sign + Encrypt, you are signing the (almost) plain text, while
with Encrypt + Sign, you are sining the cypher text so you would have to
have full trust on the Encrypt process that it did not tamper the
original text.
Also, with Sign + Encrypt, you can store the decrypted text and still
verify the
integrity of the data at a later date, but with Encrypt + Sign, you cannot.
Thus, to me, Sign + Encrypt seem to be a better approach.



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