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

["Jim Schaad" <[e-mail]>]

<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


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