Re: [jose] #23: Make crypto independent of binary encoding (base64)

["Matt Miller (mamille2)" <[e-mail]>]

I did at first find it curious why the cryptographic operations were over the base64url-enccoded values, but I was also very focused on JWE, where I think the field separation problem is less of an issue (at least now).  For JWS, this would certainly cause problems without some manner of unambiguous field parameterization.

I will note that unescaped NULL is not valid in JSON, so it could be used as a separator between the encoded header and the payload.  I do find it interesting if JOSE could more easily and efficiently support other encodings.  However, I think that while this is an interesting thought experiment, it seems we're too far down the path to seriously consider it unless the current state were shown to be horribly broken.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.

On Jun 11, 2013, at 6:01 PM, jose issue tracker <[e-mail]> wrote:

> #23: Make crypto independent of binary encoding (base64)
> 
> 
> Comment (by [e-mail]):
> 
> For both serializations, you already need the base64url encoded versions
> of the JWS Header and the JWS Payload to preserve them in transmission, so
> computing them isn't an extra burden.  In the JWS Compact Serialization,
> you already need the concatenation of the Encoded JWS Header, a period
> character, and the Encoded JWS Payload, so computing that concatenation
> isn't an extra burden.  Given you already have that quantity, computing
> the signature over it is the easiest thing for developers to do, and it's
> been shown to work well in practice.  There's no compelling reason to make
> this change.
> 
> Even for the JSON Serialization, the only "extra" step that's required to
> compute the signature is the concatenation with the period character - to
> prevent shifting of data from one field to the other, as described by Jim
> Schaad in the e-mail thread.  So this step isn't actually "extra" at all -
> it's necessary.  It's also highly advantageous to use exactly the same
> computation for both serializations, which is currently the case.
> 
> Since there is no compelling reason to make this change, and since making
> it could enable the "shifting" problem identified by Jim, it should not be
> made.
> 
> -- 
> -------------------------+-------------------------------------------------
> Reporter:  [e-mail]   |       Owner:  draft-ietf-jose-json-web-
>     Type:  defect       |  [e-mail]
> Priority:  major        |      Status:  new
> Component:  json-web-    |   Milestone:
>  encryption             |     Version:
> Severity:  -            |  Resolution:
> Keywords:               |
> -------------------------+-------------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>
> jose <http://tools.ietf.org/jose/>
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose