> -----Original Message-----
> From: Mike Jones [mailto:[email protected]]
> Sent: Sunday, August 09, 2015 9:30 PM
> To: Jim Schaad; [email protected]
> Cc: [email protected]
> Subject: RE: [jose] draft-jones-jose-jws-signing-input-options 00
>
> Thanks for your review, Jim. I've attempted to address your comments in
the -
> 01 version. Responses are inline below.
>
> -----Original Message-----
> From: jose [mailto:[email protected]] On Behalf Of Jim Schaad
> Sent: Sunday, August 02, 2015 9:02 PM
> To: [email protected]
> Cc: [email protected]
> Subject: [jose] draft-jones-jose-jws-signing-input-options 00
>
> The following represents my review of the document.
>>
> * There is only one API that I am aware of that does not support an
"Initialize,
> Update and Finalize" API for dealing with hash functions. That
> is the W3C WebCrypto API. Are there others that have the same issue?
Does
> the W3C have plans to change this so that hashing is not an atomic
operation?
>
> "sph" is gone by popular demand now, so this is no longer pertinent.
Why is this not pertinent? One could, for example, base64 the content and
hash it in chunks if one has a hash function that does IUF processing.
>
> * I don't know about Phil, but Anders wants to have clear signed for
debugging
> purposes among other things. He just wants to be able to read the message
w/o
> the base64 decoding issues. Nothing to do with what you are suggested the
> reasons are. I don't know that either of them are interested in the
compact
> serializations. The fact that you are not removing the
> base64 encoding on the transmitted protected header means that you are not
> getting all of his issues solved with this approach.
>
> He can do that if he uses "b64":false and "header" rather than "protected"
with
> the JWS JSON Serialization.
And this means that none of the controlling header data would be
authenticated correct? That might not meet his needs.
An example of this would be :
SIGN("", "ABC") === SIGN("","ABC")
Where in one case headers says "b64":true and the other says "b64":false.
Same signature but different implied content.
>
> * If the values of sph and b64 are going to be fixed by the application
and are
> not intended to be changed on a per message basis, why are they even
> parameters?
>
> So that the encodings are explicit. If "b64":false is omitted but
assumed, some
> are sure to use standard JWS libraries without the extension to emit and
> consume the JWSs, causing interop problems.
That seems to be a problem anyway. If your library does not support b64
detection it will still do bad things.
>
> * Given that a double-quote will be quoted if contained in a string for
json
> serialization, I don't understand the delimiter issue for it. You are
> signing the in memory representation and not the JSON serialized version.
> This entire issue needs far better text than it has.
>
> The better text is in the new section
https://tools.ietf.org/html/draft-ietf-jose-
> jws-signing-input-options-01#section-5.
Are % characters URL safe? What if my content for compact is %24.02 (or
whatever the correct code for $ is). Would I remove that serialization as
well?
The entire question of signing an in memory version vs a serialized out
version need to be much clearer than it is. There is an implication that
content-encoding would be removed but that should be made explicit for
detached contents as well as JSON serialization contents.
>
> * How do I go back and forth between compact and non-compact
> representations if I am signing w/o b64 and there is a period in the
> message. It does not seem to be possible.
>
> The last paragraph of Section 5 addresses this explicitly.
Given the update to section 6 - does this document need to make an "updates"
on JWT?
>
> * 7.2 para #2- what is the second property? The first is changes in
payload
> transmission
>
> The other is restricting the characters used to those that can be
successfully
> parsed.
Yes - that is part of payload transmission changes.
>
> Thanks again,
> -- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
