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

Nat Sakimura sakimura at gmail.com
Wed Oct 6 22:56:01 UTC 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101007/03c7f412/attachment-0001.html>


More information about the Openid-specs-ab mailing list