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

[Matt Miller <[e-mail]>]

On Jun 26, 2012, at 16:47, Jim Schaad wrote:

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

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 - <[e-mail]>
Cisco Systems, Inc.

/me continues goes back to ignoring that other thread (-:

> Jim
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Richard L. Barnes
>> Sent: Tuesday, June 26, 2012 3:21 PM
>> To: Mike Jones
>> Cc: John Bradley; Brian Campbell; [e-mail]
>> Subject: Re: [jose] New Version Notification for draft-barnes-jose-jsms-
>> 00.txt
>> 
>> 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;
>>    }
>> 
>> 
>> 
>> 
>> On Jun 26, 2012, at 6:03 PM, Mike Jones wrote:
>> 
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Richard L. Barnes
>>> Sent: Tuesday, June 26, 2012 10:46 AM
>>> To: Brian Campbell
>>> Cc: John Bradley; [e-mail]
>>> 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 <[e-mail]>
>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>> 
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose