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

Nat Sakimura sakimura at gmail.com
Wed Oct 6 16:48:03 UTC 2010


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


More information about the Openid-specs-ab mailing list