On Wed, 2011-09-07 at 04:37 +0000, Mike Jones wrote:
> I’m pleased to announce the publication of the first draft of the JSON
> Web Encryption (JWE) specification. It enables JSON-based encryption
> of content in a parallel manner to how the JSON Web Signature (JWS)
> specification enables JSON-based signing of content.
My comments, on excerpts from the text:
> JSON Web Encryption (JWE) is a compact encryption format intended for
> space constrained environments such as HTTP Authorization headers and
> URI query parameters.
Is there a target document size you're aiming for here (and hence can
test whether such objectives can even be met), or just
as-small-as-possible so it has the best possible chance to fit into such
environments? If it turns out that JSON is not suitable to meet these
objectives, which shall be sacrificed: JSON or compactness?
> JWE provides a wrapper for encrypted content using JSON data
> structures and base64url encoding. The representation consists of
> three parts: the JWT Header, the JWE Encrypted Key, and the JWE
> Ciphertext. The three parts are base64url-encoded for transmission,
> and typically represented as the concatenation of the encoded strings
> in that order, with the three strings being separated by period ('.')
> characters, as is done when used in JSON Web Tokens (JWTs)
You've invented a whole new structure that is not JSON. Sure, it
leverages JSON in the header, which is then base64-encoded (which I
point out also contains base64-encoded values itself, so this results in
double-base64-encoding of some values). I would argue that there should
at least be a representation that remains JSON-proper, which contains
the encrypted key and ciphertext.
> epk string String
JSON provides for the intuitive representation structured data. Why are
you choosing to encode a structured value in a string? If your answer is
"compactness" then I think we need to either rethink the use of JSON or
rethink this objective of compactness.
> jku string URL
What are the rules for accessing such keys? Can this be a URL relative
to the encrypted document, if it has a known location?
> Omitting this [kid] parameter is equivalent to setting it to an empty
> string.
Why are you allowing for empty string? What is the semantic of having it
be empty string? What about null?
> x5u string URL
Same question here as for jku.
> typ String String
Is this meant to the the Internet media type?
> For GCM, the random 64-bit IV is prepended to the ciphertext.
Isn't the "iv" property in the header already being used for this
purpose?
> 10. IANA Considerations
I recommend that a media type also be proposed, such as "application/jwe
+json".
Paul
_______________________________________________
woes mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/woes
