search

Demonware / jose

Python implementation of the Javascript Object Signing and Encryption (JOSE) framework (https://datatracker.ietf.org/wg/jose/charter/)
BSD 3-Clause "New" or "Revised" License
95 stars 34 forks source link

Plaintext should not be json-encoded. #4

Closed jaimeperez closed 9 years ago

jaimeperez commented 9 years ago

Hi,

Unless I am missing something, there's nothing in the JOSE JWE drafts saying that the plaintext used for JWE encryption must be a JSON object, nor that it must be json-encoded. Both the encrypt and the decrypt methods assume that the input must be a dict, and json-encode/decode it, making it difficult to deal with cases when you just want to encrypt a simple string. Even though we can just pass a string as a parameter and get it encrypted in the resulting JWE, this poses interoperability issues when using other libraries. If we use the example in the JWE draft, we can generate a JWE like this:

jwe = jose.encrypt('The true sign of intelligence is not knowledge but imagination.', pub_jwk)

If we then decrypt this with this library, we will get the same string. However, if we use a different library, we will get the string json-encoded, like:

"The true sign of intelligence is not knowledge but imagination."

Note the double quote signs. This is a problem because then we need to json-decode the plaintext, even though we didn't encode it when calling jose.encrypt()!

I think the best approach is to assume the plaintext to be a string, and then it is up to the user to json-encode it if he or she wants to use a JSON object. Besides, the claims jargon is confusing, and very tied to the windows world. Most people not using this library for something related to windows will be confused and won't know what's that about, specially given that claims are not mentioned at all in the JOSE drafts.

Thanks in advance!

demianbrecht commented 9 years ago

Hi @jaimeperez, thanks for the contributions.

Unless I am missing something, there's nothing in the JOSE JWE drafts saying that the plaintext used for JWE encryption must be a JSON object, nor that it must be json-encoded.

Quoting the abstract of the JWT spec:

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. Additionally, the JWT example here shows the claim set represented as a dict.

I would regard the possibility of encrypting and decrypting non JSON-encoded strings as being a bug as they don't conform to the JSON spec in that it is not contained in either an object or an array.

I think the best approach is to assume the plaintext to be a string, and then it is up to the user to json-encode it if he or she wants to use a JSON object.

As noted above, this wouldn't conform to the JWT spec.

Most people not using this library for something related to windows will be confused and won't know what's that about, specially given that claims are not mentioned at all in the JOSE drafts.

"claims" was actually a term directly from the set of RFCs. They're generally referred to as "claim sets", but I believe there are also a handful of spots that refer to them as assertions (see section 4 of the JWT RFC). If you think that the documentation is insufficient around what claims represent, then that's something that should definitely be improved.

jaimeperez commented 9 years ago

Hi Demian,

Thanks for your comments! You are absolutely right, and that's precisely what I was missing: reading the JWT spec. Quite difficult to follow when the spec is divided in so many documents and there's no clear relations between them in the text or even bad examples are used, as the ones using plain strings as the plaintext in the JWE draft spec.

Some clarifications about the claims would definitely be useful in the documentation, specially when dealing directly with JWE. But I guess it's not easy to clarify if the specs are not clear themselves and they use both the term claim and assertion.

In any case, I think we can safely close the issue. Thanks again!

demianbrecht commented 9 years ago

No worries and I couldn't agree more about how difficult it is to grok the whole thing when it's not only split up over so many documents but also still in draft status.