On Thu, Jun 27, 2013 at 7:16 PM, Mike Jones <[email protected]>wrote:
> 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.
>
It does work for the compact serialization; you just declare that the
default for the compact serialization is "b64": true. That is, you declare
the compact serialization equivalent to the following JSON object:
{
"unprotected": { "b64": true },
"protected": /* JWS Protected Header */,
"payload": /* JWS Payload */,
"signature": /* JWS Signature */
}
> 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.
>
It assumes that the protected content can be represented as a UTF-8 string.
Which is true of some large fraction of the traffic on the Internet.
> 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.
>
That was closed because the proposed solution would have broken legacy
code. The current proposal does not, because it only changes the process
when there is no protected header, which can only happen in the JSON
serialization. You're trying to inflict the limitations of the compact
format on the JSON format.
--Richard
> ****
>
> ** **
>
> 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
