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

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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard L. Barnes
Sent: Tuesday, June 26, 2012 10:46 AM
To: Brian Campbell
Cc: John Bradley; jose@ietf.org
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 <rbarnes@bbn.com> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose