0

The scenario is that the same code library is used by both client and server to encrypt/decrypt messages. The server application uses the library's encryption function to encrypt some content (that needs to be protected) and sends the serialized output as the response to a REST API request, over HTTPS, to the client. The client application uses the library's corresponding decryption function to decrypt the response. Since the same code library is used, both sides understand that the response body is a string in JWE Compact Serialization format. However, the applications on both sides do not need to know anything about the contents or its format. They just call the library's methods.

My question is: After getting the output from the encryption function, is it correct for the application on the server-side to stream it to the client with Content-Type header set to application/octet-stream? Since this is the most generic content type, I think it should be OK because the application does not care about the format of the output from the encryption function. Is this the standard practice or is there some other recommended / preferred / correct value for Content-Type of a response whose body is a string in JWE Compact Serialization format?

ADDENDUM 1: I found the specific media type application/jose as registered in the IANA Registry of media types to identify content that is a JWS or JWE object using the JWS Compact Serialization or the JWE Compact Serialization: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-31#section-9.2.1

However, I would still like to confirm that, if both sides agree that the content is to be interpreted as a JWE object, then sending Content-Type: application/octet-stream will not cause any issue.

  • Found another relevant resource: RFC 8188 Section 4.6 - specifically bullet #2. It seems reasonable to conclude that application/octet-stream is valid for any content type and basically the same as not specifying a Contet-Type header at all. – Ajoy Bhatia Nov 28 '17 at 0:27
  • I will wait for a couple of days. If there is no better answer, then I will convert previous comment into the answer. – Ajoy Bhatia Nov 28 '17 at 0:28
0

Found another relevant resource: RFC 8188 Section 4.6 - specifically bullet #2. It seems reasonable to conclude that application/octet-stream is valid for any content type and basically the same as not specifying a Content-Type header at all. It is also stated in the linked RFC that either of the options could be chosen to avoid leaking information in header fields if it is considered sensitive.

  • It has been 4 months since I made this comment on my question. Since no more authoritative or better answer has been posted, I have converted the comment into an answer. – Ajoy Bhatia Mar 29 '18 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.