[Openid-specs-ab] The other JSS envelope structure

Nat Sakimura sakimura at gmail.com
Thu Oct 7 00:48:40 UTC 2010


FYI, this is the page that describes Facebook signature.

http://developers.facebook.com/docs/authentication/canvas

=nat

On Thu, Oct 7, 2010 at 9:05 AM, John Bradley <jbradley at mac.com> wrote:

> Good point.
>
> However without a signer reference how is the RP to know who signed it to
> look up the symmetric key.
>
> In the facebook case the only place it could come from is facebook so it is
> not a issue.
>
> I need to look at that again.
>
> John B.
>
> On 2010-10-06, at 6:56 PM, Nat Sakimura wrote:
>
> There is one more benefit for using "Enveloped" approach.
>
> If we make HMAC-SHA256 the default and thus sig_params omit-able, then the
> JSON Web Token as the result of the signing is exactly what Facebook is
> doing right now, I think.
>
> =nat
>
> On Thu, Oct 7, 2010 at 2:27 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> Yes. It works for either style. Array should preserve the order -
>> otherwise, we are in trouble.
>>
>> I have no strong preference on the "enveloped" or "enveloping".
>> I will go with the majority sentiment of the group.
>>
>> =nat
>>
>>
>> On Thu, Oct 7, 2010 at 2:15 AM, John Bradley <jbradley at mac.com> wrote:
>>
>>> Using the array is a fine idea.
>>>
>>> I think it would work for either style though.
>>>
>>> The encoder needs to take a bit more care not to mix up the order.
>>>
>>> John B.
>>> On 2010-10-06, at 12:48 PM, Nat Sakimura wrote:
>>>
>>> Yes indeed.
>>>
>>> From the ease of programing point of view, there are not much difference
>>> now between the proposals.
>>>
>>> One thing that I like about Hideki's proposal is its reliance on the
>>> array.
>>> In the current draft, the signatures are indexed by the url of the key,
>>> duplicating them.
>>> His proposal removes this duplication.
>>> Also, sloppy programmer may just look at the key url supplied in the
>>> signature block and fail to match it with the one in the sig_params block,
>>> causing vulnerability. If there is no duplicate in the signature block, then
>>> one has to go and look at the sig_params and process things correctly.
>>>
>>> =nat
>>>
>>> On Thu, Oct 7, 2010 at 1:06 AM, John Bradley <jbradley at mac.com> wrote:
>>>
>>>> It mostly comes down to a style issue between the two as long as things
>>>> that process the original JSON object will safely ignore our element or it
>>>> is easily removed by the receiver.
>>>>
>>>> I admittedly tend to look at it from a XML prospective.
>>>>
>>>> The only problem with the multiple sigs in the web token format is
>>>> conflicts with what people using the MS proposed version may expect.
>>>>
>>>> I would want to talk to them about that.
>>>>
>>>> John B.
>>>>
>>>> On 2010-10-06, at 3:41 AM, Nat Sakimura wrote:
>>>>
>>>> Hi John,
>>>>
>>>> I talked with Hideki today and now understood what he meant.
>>>>
>>>> Basically, what he is proposing can essentially be reduced to:
>>>>
>>>> {
>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>    "not_after": 12345678,
>>>>    "user_id": 1223,
>>>>    "profile_id": 1223 ,
>>>>    "http://jsonenc.info/jss/sig_params" :
>>>>       [
>>>>           {
>>>>             "certs_uri": "https://example.com/mycerts.pem"
>>>>           },
>>>>           {
>>>>              "algorithm": "RSA-SHA1",
>>>>             "certs_uri": "https://example.org/mycerts.pem"
>>>>           }
>>>>        ] ,
>>>> }
>>>>
>>>> AND Signed result like:
>>>>
>>>> {
>>>>     "type": "http://openid.net/specs/ab/1.0#signed_format",
>>>>     "data_type": "application/json",
>>>>     "data": "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2FkIn0",
>>>>     "sigs": [
>>>>            "vlXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso",
>>>>            "cfXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso"
>>>>     ]
>>>> }
>>>>
>>>> sigs does not have to have the key_id or certs_uri because the order of
>>>> the array is always preserved.
>>>>
>>>> He even goes on for Web Token to be something like:
>>>>
>>>> sig1.sig2. ... .data
>>>>
>>>> so that it can have any number of signatures.
>>>>
>>>> =nat
>>>>
>>>>
>>>> On Wed, Oct 6, 2010 at 6:32 AM, John Bradley <jbradley at mac.com> wrote:
>>>>
>>>>> For security reasons the signature and hash algorithm need to be a part
>>>>> of the signed data.
>>>>> It would be easier if that were not the case.   If there only one hash
>>>>> and valid signing algorithm they could also be skipped.
>>>>>
>>>>> Allowing a attacker to modify the algorithm creates a potential
>>>>> security hole.
>>>>> This was learned  the hard way other places:)
>>>>>
>>>>> The proposed outer envelope contains the signature and payload, there
>>>>> is no collision problem there.
>>>>>
>>>>> The problem comes from trying to insert our signature elements into
>>>>> someone else's JSON object.
>>>>>
>>>>> That mostly happens if they happen to be using env for something else.
>>>>>
>>>>> Unless we choose a URI for our element names, we run the rusk of
>>>>> colliding.
>>>>>
>>>>> Perhaps I am lazy, it just seems easier to me, to keep the objects
>>>>> separate.
>>>>>
>>>>> John B.
>>>>>
>>>>> On 2010-10-05, at 5:15 PM, nara hideki wrote:
>>>>>
>>>>> > Thanks John,
>>>>> >
>>>>> > I might misunderstood something, but there doesn't  seems to be
>>>>> > namespace collision because the whole (root) JSON object
>>>>> > including envelope JSON object is to be canonicalized in base64url
>>>>> > format and set to "data" in JSON Serialization.
>>>>> >
>>>>> > I'd like to know the reason why  envelope JSON MUST not be included
>>>>> in
>>>>> > signature base string.
>>>>> >
>>>>> > Regards
>>>>> >
>>>>> > ----
>>>>> > hdknr
>>>>> >
>>>>> >
>>>>> > 2010/10/6 John Bradley <jbradley at mac.com>:
>>>>> >> True, but we still have the problem of conflicting with elements in
>>>>> the object that we are trying to sign.
>>>>> >>
>>>>> >> It is also harder to recover the original object at the end of the
>>>>> process if you don't keep it separate.
>>>>> >>
>>>>> >> I see this as an enveloping signature where the original JSON is
>>>>> contained in a single element and can be easily extracted.
>>>>> >>
>>>>> >> You are going for more of an enveloped style where the signature
>>>>> elements become part of the object.
>>>>> >>
>>>>> >> If we weren't forced to base64 the entire thing for calculating the
>>>>> signature over I would probably favour your method.
>>>>> >>
>>>>> >> It would allow for you to receive an object and ignore the sig if
>>>>> you don't care about it.
>>>>> >>
>>>>> >> We cant do that in this case because the receiver must always unwrap
>>>>> the base64 encoding.
>>>>> >>
>>>>> >> So the most you can get out of the enveloped signature method is
>>>>> that after you receive JSON object and extract the encoded JSON object you
>>>>> have almost the object that you had when you started the signing process.
>>>>> >>
>>>>> >> In the Enveloping signature method you still need to extract the
>>>>> JSON form the payload.   The advantage is what goes in comes out, and there
>>>>> are no namespace issues.
>>>>> >>
>>>>> >> I am not super attached to the idea, but that is my reasoning.
>>>>> >>
>>>>> >> John B.
>>>>> >> On 2010-10-05, at 3:42 PM, nara hideki wrote:
>>>>> >>
>>>>> >>> John, Nat , Thank you for your description.
>>>>> >>>
>>>>> >>> For multiple signers, this may work as well:
>>>>> >>>
>>>>> >>> {
>>>>> >>>     "param1" : "xxxxx",
>>>>> >>>     "param2" : "xxxxx",
>>>>> >>>      ....
>>>>> >>>     "env1":  {
>>>>> >>>            "type": "http://jsonenc.info/jss/",
>>>>> >>>             "key_id": "signer1.com",
>>>>> >>>             "algorithm": "HMAC-SHA256"
>>>>> >>>              ...
>>>>> >>>      },
>>>>> >>>     "env2":  {
>>>>> >>>            "type": "http://jsonenc.info/jss/",
>>>>> >>>             "key_id": "signer2.com",
>>>>> >>>             "algorithm": "HMAC-SHA256"
>>>>> >>>              ...
>>>>> >>>      },
>>>>> >>> }
>>>>> >>>
>>>>> >>> In the above implementation, "env1" and "env2" can be used as
>>>>> >>> identifiers(indexer) for signature
>>>>> >>> in JSON Serialization later.
>>>>> >>>
>>>>> >>>
>>>>> >>> For arbitrary binary enveloping,  we can freely put any
>>>>> base64url-ed
>>>>> >>> string in JSON fields anyway.
>>>>> >>> For simplicity, I think that JSS should target on only JSON.
>>>>> >>>
>>>>> >>> ----
>>>>> >>> hdknr
>>>>> >>>
>>>>> >>> 2010/10/6 Nat Sakimura <sakimura at gmail.com>:
>>>>> >>>> There actually was another reason for having "payload" as a
>>>>> parameter.
>>>>> >>>> As a generic signature mechanism, we may want to sign arbitrary
>>>>> binary
>>>>> >>>> data.
>>>>> >>>> In such a case, we can base64url encode it and put it into
>>>>> "payload"
>>>>> >>>> parameter.
>>>>> >>>> =nat
>>>>> >>>>
>>>>> >>>> On Wed, Oct 6, 2010 at 12:56 AM, Nat Sakimura <sakimura at gmail.com>
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> In this example:
>>>>> >>>>> {
>>>>> >>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>> >>>>>    "not_after": 12345678,
>>>>> >>>>>    "user_id": 1223,
>>>>> >>>>>    "profile_id": 1223 ,
>>>>> >>>>>    "env" :
>>>>> >>>>>    {
>>>>> >>>>>        "type": "http://jsonenc.info/jss/",
>>>>> >>>>>        "sig_params": [
>>>>> >>>>>            {
>>>>> >>>>>                "key_id": "example.com",
>>>>> >>>>>                "algorithm": "HMAC-SHA256"
>>>>> >>>>>            }
>>>>> >>>>>        ]
>>>>> >>>>>    }
>>>>> >>>>> }
>>>>> >>>>> I do not think we need env. That would simplify.
>>>>> >>>>> The reason why we put everything inside the payload was that we
>>>>> thought it
>>>>> >>>>> would be easier to process. I am open to both ways.
>>>>> >>>>> What do others think?
>>>>> >>>>> =nat
>>>>> >>>>> On Wed, Oct 6, 2010 at 12:40 AM, nara hideki <
>>>>> hdknr at ic-tact.co.jp> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Hi, Nat,
>>>>> >>>>>>
>>>>> >>>>>> This revision of envelope is literally "envelope" in which
>>>>> parameters
>>>>> >>>>>> in concern are held as JSON object in "payload".
>>>>> >>>>>> But it looks more simpler to me if all signing parameters are
>>>>> held as
>>>>> >>>>>> a JSON object in the concerned data.  I mean that the following
>>>>> sample
>>>>> >>>>>> :
>>>>> >>>>>>
>>>>> >>>>>> {
>>>>> >>>>>>    "type": "http://jsonenc.info/jss/",
>>>>> >>>>>>    "sig_params": [
>>>>> >>>>>>        {
>>>>> >>>>>>            "key_id": "example.com",
>>>>> >>>>>>            "algorithm": "HMAC-SHA256"
>>>>> >>>>>>        }
>>>>> >>>>>>    ],
>>>>> >>>>>>    "payload": {
>>>>> >>>>>>        "oauth_token": "asdfjklsdfjwoIjfk",
>>>>> >>>>>>        "not_after": 12345678,
>>>>> >>>>>>        "user_id": 1223,
>>>>> >>>>>>        "profile_id": 1223
>>>>> >>>>>>    }
>>>>> >>>>>> }
>>>>> >>>>>>
>>>>> >>>>>> can be simplified in this JSON:
>>>>> >>>>>>
>>>>> >>>>>> {
>>>>> >>>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>> >>>>>>    "not_after": 12345678,
>>>>> >>>>>>    "user_id": 1223,
>>>>> >>>>>>    "profile_id": 1223 ,
>>>>> >>>>>>    "env" :
>>>>> >>>>>>    {
>>>>> >>>>>>        "type": "http://jsonenc.info/jss/",
>>>>> >>>>>>        "sig_params": [
>>>>> >>>>>>            {
>>>>> >>>>>>                "key_id": "example.com",
>>>>> >>>>>>                "algorithm": "HMAC-SHA256"
>>>>> >>>>>>            }
>>>>> >>>>>>        ]
>>>>> >>>>>>    }
>>>>> >>>>>> }
>>>>> >>>>>>
>>>>> >>>>>> because if the original parameters without a signature can be
>>>>> following :
>>>>> >>>>>>
>>>>> >>>>>> {
>>>>> >>>>>>    "oauth_token": "asdfjklsdfjwoIjfk",
>>>>> >>>>>>    "not_after": 12345678,
>>>>> >>>>>>    "user_id": 1223,
>>>>> >>>>>>    "profile_id": 1223
>>>>> >>>>>> }
>>>>> >>>>>>
>>>>> >>>>>>> From the programming effort's point of view, it doesn't make
>>>>> any
>>>>> >>>>>> difference.
>>>>> >>>>>> But JSON text looks simpler.
>>>>> >>>>>>
>>>>> >>>>>> We don't have to define holding parameter name as "env" because
>>>>> JSS
>>>>> >>>>>> JSON object MUST have
>>>>> >>>>>> "type". In Python, this code can be tell whether a JSON is
>>>>> JSS-envloped
>>>>> >>>>>> or not:
>>>>> >>>>>>
>>>>> >>>>>>>>> j=simplejson.loads( source_json_text )
>>>>> >>>>>>>>> True in [  type(v)==dict and v.has_key('type') and v['type']
>>>>> ==
>>>>> >>>>>>>>> "http://jsonenc.info/jss/" for k,v in j.iteritems()]
>>>>> >>>>>> True
>>>>> >>>>>>
>>>>> >>>>>> A drawback is a fact that "env" dosen't look literally an
>>>>> envelope.
>>>>> >>>>>>
>>>>> >>>>>> ---
>>>>> >>>>>> hideki
>>>>> >>>>>> _______________________________________________
>>>>> >>>>>> Openid-specs-ab mailing list
>>>>> >>>>>> Openid-specs-ab at lists.openid.net
>>>>> >>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> --
>>>>> >>>>> Nat Sakimura (=nat)
>>>>> >>>>> http://www.sakimura.org/en/
>>>>> >>>>> http://twitter.com/_nat_en
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Nat Sakimura (=nat)
>>>>> >>>> http://www.sakimura.org/en/
>>>>> >>>> http://twitter.com/_nat_en
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> Openid-specs-ab mailing list
>>>>> >>>> Openid-specs-ab at lists.openid.net
>>>>> >>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> >>>>
>>>>> >>>>
>>>>> >>> _______________________________________________
>>>>> >>> Openid-specs-ab mailing list
>>>>> >>> Openid-specs-ab at lists.openid.net
>>>>> >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> >>
>>>>> >>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>> http://twitter.com/_nat_en
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>> http://twitter.com/_nat_en
>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101007/640758c6/attachment-0001.html>


More information about the Openid-specs-ab mailing list