Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

From: Mike Jones <[email-masked]>
Date: Tue, 26 Jun 2012 22:03:25 +0000

http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-01 is an existence proof that it's not hard to sign the parameters and have multiple signatures.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Tuesday, June 26, 2012 10:46 AM
To: Brian Campbell
Cc: John Bradley; [email-masked]
Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-00.txt

I agree with that goal!  I disagree that JWS is a good solution.  

It is true that JWS provides a relatively simple mechanism for a single signature, but:
1. It could be simpler (see below)
2. JWS header protection is useless for the single-signature case, and makes the multiple-signature/recipient case harder

--Richard

On Jun 26, 2012, at 12:16 PM, Brian Campbell wrote:

> I wasn't suggesting that integrity-protecting the header itself makes 
> things simpler. Rather that a desirable goal is for support of a 
> relatively simple model utilizing a single signature over the whole 
> message. And that we already have that in JWS.
> 
> On Mon, Jun 25, 2012 at 3:55 PM, Richard L. Barnes <[email-masked]> wrote:
>> 
>> On Jun 25, 2012, at 5:53 PM, Richard L. Barnes wrote:
>> 
>>>>> I think part of this is that as one of the openID Connect authors I look at this as a necessary security token format, for OAuth and Connect.
>>>>> For that simple processing with one signature is a high priority for adoption.
>>>> 
>>>> +1.
>>>> 
>>>> A simple JSON friendly model supporting a single signature over the 
>>>> entire message (including headers) is an important case for 
>>>> adoption (and security). JWS provides that now and there are 
>>>> already numerous interoperable JWS implementations available or in the works.
>>> 
>>> I'm not sure how people think that integrity-protecting the header makes things *simpler*, especially since it adds a whole new decoding step and makes the parsing more complicated.
>>> 
>>> Pseudocode without integrity protection (assuming JSMS format, but JWS could be made to look similar):
>>> function verify(json) {
>>>    jose = JSON.parse(json);
>>>    // Check algorithm values
>>>    return Crypto.SignatureAlgorithm.verify(jose.content, 
>>> jose.keys[0].signature, jose.keys[0].key); }
>>> 
>>> Pseudocode with integrity protection (assuming JWS format):
>>> function verify(jws) {
>>>    (txtHeader, content, signature) = jws.split("\.");
>>>    protectedBody = header + "." + content
>>>    jsonHeader = base64url.decode(txtHeader);
>>>    header = JSON.parse(jsonHeader);
>>>    return Crypto.SignatureAlgorithm.verify(content, signature, 
>>> header.jwk); }
>>> 
>> 
>> Err, sorry, that should read:
>>    protectedBody = txtHeader + "." + content; and
>>    return Crypto.SignatureAlgorithm.verify(protectedBody, signature, 
>> header.jwk);
>> 
>> See how hard it is to get right?  :)
>> 
>> --Richard
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 18:21:12 -0400

Sure, multiple signature is easier than multiple recipients.  But I wouldn't call it simple.  I have to base64url-decode each header to figure out which one to use (but keep around the encoded version, so I can verify the signature), keep track of the corresponding signature value, and reconstruct the signed body -- all before I can do the actual signature verification.

OTOH, without integrity-protection, you can just have the signature beside all the other parameters, in plain JSON, so that you can just grab stuff and go.

From <https://raw.github.com/bifurcation/jsms/master/jose.js>:

    verify: function(object) {
        var jsms = JSON.parse(object);
        if (!_JOSE_Support.isSignedData(jsms)) {
            throw "Invalid SignedData object";
        }

        // Figure out which signatures are valid
        var validPublicKeys = [];
        var sigs = jsms.signatures;
        for (var i=0; i<sigs.length; ++i) {
            var result = _JOSE_Crypto.verify_pkcs1_sha256(
                sigs[i].key.n, sigs[i].key.e, jsms.content, sigs[i].signature)
            if (result = "True") {
                validPublicKeys.push(sigs[i].key);
            }
        }

        return validPublicKeys;
    }

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jun 2012 18:23:58 -0400

> OTOH, without integrity-protection, you can just have the signature beside all the other parameters, in plain JSON, so that you can just grab stuff and go.

Addendum: This assumes that you're doing the base64-encoding thing to allow integrity protection.  If we do canonicalization, this issue goes away.  But then we have to do canonicalization.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Jun 2012 15:47:33 -0700

<no hat>

Note that with my proposal this is somewhat easier.  Also given that we are
dealing with garbage collection systems it is likely that this data has not
yet disappeared from memory anyway as long as it is referenced.  The header
information is not going to be megabytes in size and all of that processing
on the headers can be done before you hash and decode the body.

Jim

> Sent: Tuesday, June 26, 2012 3:21 PM
> To: Mike Jones
> Cc: John Bradley; Brian Campbell; [email-masked]
> Sure, multiple signature is easier than multiple recipients.  But I
wouldn't call
> it simple.  I have to base64url-decode each header to figure out which one
to
> use (but keep around the encoded version, so I can verify the signature),
> keep track of the corresponding signature value, and reconstruct the
signed
> body -- all before I can do the actual signature verification.
> 
> OTOH, without integrity-protection, you can just have the signature beside
> all the other parameters, in plain JSON, so that you can just grab stuff
and go.
> > http://tools.ietf.org/html/draft-jones-json-web-signature-json-
> serialization-01 is an existence proof that it's not hard to sign the
parameters
> and have multiple signatures.
> >
> > 				-- Mike
> >
> > 2. JWS header protection is useless for the single-signature case, and
> > makes the multiple-signature/recipient case harder
> >
> > --Richard
> >
> >
> >
> >>>>>> I think part of this is that as one of the openID Connect authors I
look
> at this as a necessary security token format, for OAuth and Connect.
> >>>>>> For that simple processing with one signature is a high priority
for
> adoption.
> >>>>>
> >>>>> +1.
> >>>>>
> >>>>> A simple JSON friendly model supporting a single signature over
> >>>>> the entire message (including headers) is an important case for
> >>>> I'm not sure how people think that integrity-protecting the header
> makes things *simpler*, especially since it adds a whole new decoding step
> and makes the parsing more complicated.
> >>>>

---

From: Matt Miller <[email-masked]>
Date: Tue, 26 Jun 2012 18:46:30 -0600

> on the headers can be done before you hash and decode the body.

The simplicity of JSON means its appeal is well beyond JavaScript; assuming there is always a garbage collector is not valid in my opinion.

However, I also don't think keeping an extra reference to base64url-encoded data is prohibitively expensive.  It might be (slightly) more error-prone on the implementor, but again I do not think is it prohibitively so.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.