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

John Bradley jbradley at mac.com
Thu Oct 7 16:54:54 UTC 2010


I think Nat was proposing that if the default signing alg is HMAC-SHA256 then we would not need to insert the element containing the signing info into whatever JSON object was being signed.

However we have key_id as REQUIRED so we need to insert that element unless we remove the requirement.

I do understand that in the simplest of cases you may not need it, however I think it is better to include it.

John B.


On 2010-10-07, at 2:44 AM, Anthony Nadalin wrote:

> I don’t see why the key_id would have to be removed
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
> Sent: Wednesday, October 06, 2010 6:22 PM
> To: Nat Sakimura
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] The other JSS envelope structure
>  
> I see.
>  
> We would need to remove key_id as REQUIRED for HMAC-SHA256 to make that work.
>  
> So if you are using it in a proprietary situation you could omit the key_id.  
> I think that is probably a bad idea for interoperability.   It works for them because the protocol is effectively closed a RP would only ever have one key.
>  
> John B.
>  
> On 2010-10-06, at 8:48 PM, Nat Sakimura wrote:
> 
> 
> 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/75bd7fb4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101007/75bd7fb4/attachment-0001.bin>


More information about the Openid-specs-ab mailing list