+1. KISS.
On Thu, Jun 27, 2013 at 9:01 PM, Edmund Jay <[email protected]> wrote: > I prefer keeping the base64url encoded payload as that will result in > simpler code paths and better interoperability. > As Mike pointed out, there could be problems with compact serialization if > you turn b64 off. > > ------------------------------ > *From:* Mike Jones <[email protected]> > *To:* Richard Barnes <[email protected]>; Jim Schaad <[email protected]> > *Cc:* n-sakimura <[email protected]>; "[email protected]" <[email protected]>; > "[email protected]" < > [email protected]> > *Sent:* Thursday, June 27, 2013 4:16 PM > > *Subject:* Re: [jose] #26: Allow for signature payload to not be base64 > encoded > > Even if we chose to support an unencoded payload representation as an > option for the JSON Serialization (which I’m not advocating), having this > be the default would be the wrong thing for two reasons: > > 1. It won’t work for the Compact Serialization, since it doesn’t ensure > that the representation is URL-safe. The default should work for both > serializations. > > 2. It assumes a special case (a payload that can be represented as a > transport-invariant JSON string), which will often not work. The default > should be the general case, which always works. > > As for your suggestion to not use the base64url encoded payload in the > signature computation, this seems to me like an attempt to reopen > http://trac.tools.ietf.org/wg/jose/trac/ticket/23 (Make crypto > independent of binary encoding (base64)) by another means, despite it > already being resolved as “Won’t Fix”. I don’t believe that constantly > trying to revisit closed issues is a productive activity, nor respectful of > the working group’s time, so I therefore request that you let that one go. > > Sincerely, > -- Mike > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, June 27, 2013 3:24 PM > *To:* Jim Schaad > *Cc:* Mike Jones; n-sakimura; [email protected]; > [email protected] > *Subject:* Re: [jose] #26: Allow for signature payload to not be base64 > encoded > > I think there are two separable issues here, both of which Mike and I > probably have divergent opinions on :) > 1. Syntax: Should it be possible for the "payload" field JWS to be a > JSON string (instead of base64) when the payload is simply a UTF-8 string? > 2. Crypto: Must the JWS Signing Input be base64url encoded. > > The current answers to these questions are: > 1. It is not possible. Payload is always base64url encoded. > 2. It is always base64url encoded. > > The answers should be: > 1. The payload should not be base64url encoded unless it cannot be > represented as a JSON string. > 2. The JWS Signing Input should not be base64url encoded unless there is > a JWS Protected Header > > Neither of these are complicated changes: > 1. Add a "b64" header parameter that indicates that the payload is > base64url-encoded binary, as opposed to a UTF-8 string. Specify that this > parameter is on by default in compact-formatted JWS objects. > 2. Modify the signing/verification instructions to switch based on the > presence of a JWS Protected Header: "If the JWS Protected Header is absent > or empty, then the JWS Signing Input is simply the JWS Payload (not > encoded). If the JWS Protected Header has a non-empty value, then the the > JWS Signing Input is the concatenation of the Encoded JWS Header, a period > ('.') character, and the Encoded JWS Payload" > > There are two reasons for these, both of which are important to make > sure that this spec is applicable to a broad variety of use cases: > 1. Compactness. As Jim notes, quoted strings are shorter than > base64url-encoded strings > 2. Crypto-compatibility: Avoiding base64-encoding means that there's > nothing JWS-specific about the signature value. So for example, you could > translate a JWS with no protected attributes to a CMS SignedData object > with no protected attributes. > > This email brought to you by the number 2 and the letters J, W, and S :) > > --Richard > > [1] Note that the default value for this header must be false, or else > you lose the compactness advantage! > [2] You could also do this as a "Content-Encoding" equivalent, "cenc": > "b64". That would give you "base64 agility", as some folks have asked for, > since you could have "b64" and "b64u" values. > [3] You could also do this like CMS, and have the JWS Signing Input in > the latter case be "the concatenation of the Encoded JWS Header, a period > ('.') character, and the Encoded JWS Payload Hash". Where the Encoded JWS > Payload Hash is the base64url-encoded version of the hash you would > otherwise be signing. This seems simpler to code, since you just digest > the body, then if there's a protected header, you digest again. But it > also breaks with existing code. > > > > > On Thu, Jun 27, 2013 at 1:11 PM, Jim Schaad <[email protected]> > wrote: > No, my motivation is to allow for a smaller version of the payload string. > In some cases quoting it will generate a smaller string than doing the > base64 conversion on the string. > > > > > -----Original Message----- > > From: Mike Jones [mailto:[email protected]] > > Sent: Thursday, June 27, 2013 9:49 AM > > To: Jim Schaad; 'n-sakimura' > > Cc: [email protected]; [email protected] > > Subject: RE: [jose] #26: Allow for signature payload to not be base64 > encoded > > > > Jim, you wrote "If I am not transporting the base64url encoded content, > > because it is not in the "payload" field, then why should I need to > base64 > > encode it just to validate the signature. This is the alto case." > > > > So am I correct then, in thinking that your motivation for #26 is > actually #25 - > > Detached content for the ALTO use case? As John and Nat had written, > this > > could be handled by the specs as they are today by signing a hash of the > > detached content and including a compact JWS representing that signature > as > > an x-alto-signature header. That doesn't require changing the signature > > calculation. > > > > -- Mike > > > > -----Original Message----- > > From: Jim Schaad [mailto:[email protected]] > > Sent: Thursday, June 27, 2013 9:41 AM > > To: 'n-sakimura' > > Cc: [email protected]; Mike Jones; > > [email protected] > > Subject: RE: [jose] #26: Allow for signature payload to not be base64 > encoded > > > > Nat, > > > > The only thing that can be signed or encrypted is an octet string. (A > slight over > > generalization. GOST for example hashes an integer, tree hashes can do > > strange things but a sufficiently true statement for our purposes.) > > > > A that being said - yes case 1 would be something you can do. Case #2 > would > > not be something that you can do because it is not an octet string. > > > > If you are looking at JavaScript, in order to hash something as an octet > string it > > can be one of three things. A UInt8Array, an Int8Array and, due to > > convention, a string where the top byte of all of the code points in the > string is > > zero. > > > > We currently don't have an efficient way to encode the Uint8Array case, > > although that might not be true if we are looking at new ECMA > specifications > > which apparently are adding more defined types and serialization methods > for > > those types. > > > > > -----Original Message----- > > > From: n-sakimura [mailto:[email protected]] > > > Sent: Wednesday, June 26, 2013 7:55 PM > > > To: Jim Schaad > > > Cc: [email protected]; > > > [email protected]; [email protected] > > > Subject: Re: [jose] #26: Allow for signature payload to not be base64 > > > encoded > > > > > > Let me understand the problem. > > > > > > Are you suggesting that we should be able to do something like: > > > > > > Case 1: > > > > > > {"protected":<integrity-protected shared header contents>", > > > "unprotected":<non-integrity-protected shared header contents>", > > > "payload":"this is a multi\nline text payload of which a line > > > can be very very very long and wrapped during transmission. " > > > "signatures":[ > > > {"header":"<per-signature unprotected header 1 contents>", > > > "signature":"<signature 1 contents>"}, > > > ... > > > {"header":"<per-signature unprotected header N contents>", > > > "signature":"<signature N contents>"}], > > > } > > > > > > or even > > > > > > Case 2: > > > > > > {"protected":<integrity-protected shared header contents>", > > > "unprotected":<non-integrity-protected shared header contents>", > > > "payload":{ > > > "this":"is a json", > > > "payload":"which is not base64url encoded" > > > } > > > "signatures":[ > > > {"header":"<per-signature unprotected header 1 contents>", > > > "signature":"<signature 1 contents>"}, > > > ... > > > {"header":"<per-signature unprotected header N contents>", > > > "signature":"<signature N contents>"}], > > > } > > > > > > Then, I am worried about allowing them because in general we would not > > > know what would a transmission mechanism and user agents (including > > > text > > > editors) would do to them, like Mike mentioned. I do not think we > > > should assume the property of the transmission mechanism in JOSE level. > > > Assuming that would cause brittleness in the implementations. > > > > > > For detached signature, I do not understand why you would want non- > > > base64url encoded payload. The application should define how to hash > > > the octet stream that it wants to calculate signature over it, and we > > > can just include the base64url encoded hash in the "payload". > > > Why would you like to do other encoding for the hash? > > > > If I am not transporting the base64url encoded content, because it is > not in > > the "payload" field, then why should I need to base64 encode it just to > > validate the signature. This is the alto case. > > > > Jim > > > > > > > > -- > > > Nat Sakimura ([email protected]) > > > Nomura Research Institute > > > > > > PLEASE READ: > > > The information contained in this e-mail is confidential and intended > > > for the named recipient(s) only. > > > If you are not an intended recipient of this e-mail, you are hereby > > > notified that any review, dissemination, distribution or duplication > > > of this message is strictly prohibited. If you have received this > > > message in error, please notify the sender immediately and delete your > > copy from your system. > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
