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

nara hideki hdknr at ic-tact.co.jp
Thu Oct 7 05:45:37 UTC 2010


Nat and John, thank you for your clarification.

Because I didn't have deep knowledge about Javascript,  I was not
quite sure if we can use URI as JSON attribute.
I checked with node.js( engine is google V8) ,a server side
javascript, that it works as an associative array's key in Javascript
object.
So I think that "enveloped" version can work.

source:

(main)hdknr at deblen:tmp$ more openid.js
var src='\
{\
   "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"\
          }\
      ] \
}';
envelope = JSON.parse(src);
console.log( envelope['http://jsonenc.info/jss/sig_params']);
console.log("type is " + typeof(
envelope['http://jsonenc.info/jss/sig_params']));

execution on node.js

(main)hdknr at deblen:tmp$ node  openid.js
[ { certs_uri: 'https://example.com/mycerts.pem' }
, { algorithm: 'RSA-SHA1'
  , certs_uri: 'https://example.org/mycerts.pem'
  }
]
type is object





2010/10/6 Nat Sakimura <sakimura at gmail.com>:
> 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
>


More information about the Openid-specs-ab mailing list