Re: [jose] #26: Allow for signature payload to not be base64 encoded

[Matias Woloski <[e-mail]>]

+1. KISS.


On Thu, Jun 27, 2013 at 9:01 PM, Edmund Jay <[e-mail]> 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 <[e-mail]>
> *To:* Richard Barnes <[e-mail]>; Jim Schaad <[e-mail]>
> *Cc:* n-sakimura <[e-mail]>; "[e-mail]" <[e-mail]>;
> "[e-mail]" <
> [e-mail]>
> *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:[e-mail]]
> *Sent:* Thursday, June 27, 2013 3:24 PM
> *To:* Jim Schaad
> *Cc:* Mike Jones; n-sakimura; [e-mail];
> [e-mail]
> *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 <[e-mail]>
> 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:[e-mail]]
>   > Sent: Thursday, June 27, 2013 9:49 AM
> > To: Jim Schaad; 'n-sakimura'
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail]]
> > Sent: Thursday, June 27, 2013 9:41 AM
> > To: 'n-sakimura'
> > Cc: [e-mail]; Mike Jones;
> > [e-mail]
> > 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:[e-mail]]
> > > Sent: Wednesday, June 26, 2013 7:55 PM
> > > To: Jim Schaad
> > > Cc: [e-mail];
> > > [e-mail]; [e-mail]
> > > 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 ([e-mail])
> > > 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
> [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
>
>