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

Nat Sakimura sakimura at gmail.com
Thu Oct 7 16:59:48 UTC 2010


I also think that it is better to have key_id for interoperability.

The delta is small enough that hopefully it should not matter too much for
them to include those as well.

=nat

On Fri, Oct 8, 2010 at 1:54 AM, John Bradley <jbradley at mac.com> wrote:

> 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
>
>
>
>


-- 
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/20101008/4f99d99b/attachment-0001.html>


More information about the Openid-specs-ab mailing list