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

Nat Sakimura sakimura at gmail.com
Wed Oct 6 17:27:06 UTC 2010


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


More information about the Openid-specs-ab mailing list