Subject: Re: [jose] issue #25 TEXT

From: Mike Jones <[email-masked]>
Date: Mon, 4 Nov 2013 18:33:51 +0000

Per my action item from the last call, I propose the following text to address issue #25:

8.  Detached Content

In some contexts, it is useful integrity protect content that is not itself contained in a JWS object.  There are two suggested ways of accomplishing this using JWS objects.

One way is create a JWS object containing the payload in the normal fashion, but then delete the payload representation, and send this modified object to the recipient, rather than the JWS.  This method assumes that the recipient has access to the exact payload used in the JWS.  When using the JWS Compact Serialization, the deletion is accomplished by replacing the second field (which contains BASE64URL(JWS Payload)) value with the empty string; when using the JWS JSON Serialization, the deletion is accomplished by deleting the "payload" member.  To use the modified object, the recipient reconstructs the JWS by re-inserting the payload representation into the modified object, and uses the resulting JWS in the usual manner.  Note that this method needs no support from JWS libraries, as applications can use this method by modifying the inputs and outputs of standard JWS libraries.

Another way to accomplish this is to have the JWS Payload be or include a cryptographic hash of the detached content.  The application might also include an identifier for the hash algorithm used in the JWS payload.  To use this JWS, the recipient validates the JWS in the usual way and verifies that the hash value contained in the JWS payload matches a cryptographic hash of the detached content computed by the recipient.  This method also needs no support from JWS libraries.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, September 29, 2013 1:08 PM
To: Mike Jones
Cc: [email-masked]
Subject: issue #25 TEXT

The following provides suggested text for addressing Issue #25

Jim

Text for the JWS document:

Section 7.2.1  Detached Content

Applications can do detached content with the JSON serialization.  Detached content has the benefit of allowing the content to be transmitted in a more natural format, and to avoid the expansion associated with applying the base64 transformation.  It has the downside that how the content is serialized into a text string is not preserved and therefore some type of canonicalization process may need to be applied by both the sender and the recipient.  In some circumstances this is not an issue (signing a binary file), while in other circumstances it can be problematic (end of line characters or ordering of JSON objects).  Applications cannot rely on this feature to be implemented by libraries but need to do it themselves.

On serialization, the application removes the payload value from the JSON structure before writing it out.  The contents of the signed field are then transmitted separately from the JWS structure.  For instance, the JWS serialized JSON structure could be transmitted as an HTTP header field, while the content is transmitted as  the content of the HTTP body.

On deserialization, the application obtains the to be signed value from where it is transferred, applies the necessary canonicalization and encoding to it before creating the "payload" member of the JSON structure and passing the resulting object to the library for processing.

Text for the JWE document:

Section 7.2.1 Detached Content

Applications can do detached content with the JSON serialization.  Detached content has the benefit of allowing the content to be transmitted in a more natural format, and to avoid the expansion associated with applying the base64 transformation.  Since the output of the encryption process is always an octet string, there are no canonicalization issues associated with transporting the encrypted string separately from the encryption header.

On serialization, the application removes the "ciphertext" field from the JSON structure before writing it out.  The contents of the "ciphertext" field then have the base64 encoding removed and it is transmitted separated from the JWE structure.  For instance, the JWE serialized JSON structure could be transmitted as an HTTP header field, while the cipher  text could be transmitted using binary transfer encoding as the HTTP body.

On deserialization, the application obtains the cipher text from where it was transferred, applies the base64 transfer encoding and places it in the "ciphertext" member of the JWE JSON structure.  The resulting object is then passed to the JOSE library for process.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Nov 2013 11:35:32 -0800

The only problem that I have with the text in the last paragraph is that it
does not discuss where and how the hash algorithm is registered so that each
application does not create its own registry of hash algorithms but uses a
common one.  This could be done by having a new document that defines a body
type for this and point, but that is a new document that would need to be
written and discussed.

I also don't care for the second sentence.  The assumption is that the
recipient can create the exact payload rather than has access to it.  For
example adding the base64 wrapping is not an issue in terms of re-creating
the content.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Monday, November 04, 2013 10:34 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [jose] issue #25 TEXT

Per my action item from the last call, I propose the following text to
address issue #25:

8.  Detached Content

In some contexts, it is useful integrity protect content that is not itself
contained in a JWS object.  There are two suggested ways of accomplishing
this using JWS objects.

One way is create a JWS object containing the payload in the normal fashion,
but then delete the payload representation, and send this modified object to
the recipient, rather than the JWS.  This method assumes that the recipient
has access to the exact payload used in the JWS.  When using the JWS Compact
Serialization, the deletion is accomplished by replacing the second field
(which contains BASE64URL(JWS Payload)) value with the empty string; when
using the JWS JSON Serialization, the deletion is accomplished by deleting
the "payload" member.  To use the modified object, the recipient
reconstructs the JWS by re-inserting the payload representation into the
modified object, and uses the resulting JWS in the usual manner.  Note that
this method needs no support from JWS libraries, as applications can use
this method by modifying the inputs and outputs of standard JWS libraries.

Another way to accomplish this is to have the JWS Payload be or include a
cryptographic hash of the detached content.  The application might also
include an identifier for the hash algorithm used in the JWS payload.  To
use this JWS, the recipient validates the JWS in the usual way and verifies
that the hash value contained in the JWS payload matches a cryptographic
hash of the detached content computed by the recipient.  This method also
needs no support from JWS libraries.

                                                            -- Mike

Jim

Applications can do detached content with the JSON serialization.  Detached
content has the benefit of allowing the content to be transmitted in a more
natural format, and to avoid the expansion associated with applying the
base64 transformation.  It has the downside that how the content is
serialized into a text string is not preserved and therefore some type of
canonicalization process may need to be applied by both the sender and the
recipient.  In some circumstances this is not an issue (signing a binary
file), while in other circumstances it can be problematic (end of line
characters or ordering of JSON objects).  Applications cannot rely on this
feature to be implemented by libraries but need to do it themselves.

On serialization, the application removes the payload value from the JSON
structure before writing it out.  The contents of the signed field are then
transmitted separately from the JWS structure.  For instance, the JWS
serialized JSON structure could be transmitted as an HTTP header field,
while the content is transmitted as  the content of the HTTP body.

On deserialization, the application obtains the to be signed value from
where it is transferred, applies the necessary canonicalization and encoding
to it before creating the "payload" member of the JSON structure and passing
the resulting object to the library for processing.

Applications can do detached content with the JSON serialization.  Detached
content has the benefit of allowing the content to be transmitted in a more
natural format, and to avoid the expansion associated with applying the
base64 transformation.  Since the output of the encryption process is always
an octet string, there are no canonicalization issues associated with
transporting the encrypted string separately from the encryption header.

On serialization, the application removes the "ciphertext" field from the
JSON structure before writing it out.  The contents of the "ciphertext"
field then have the base64 encoding removed and it is transmitted separated
from the JWE structure.  For instance, the JWE serialized JSON structure
could be transmitted as an HTTP header field, while the cipher  text could
be transmitted using binary transfer encoding as the HTTP body.

On deserialization, the application obtains the cipher text from where it
was transferred, applies the base64 transfer encoding and places it in the
"ciphertext" member of the JWE JSON structure.  The resulting object is then
passed to the JOSE library for process.

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Nov 2013 19:54:28 +0000

While defining the hash function names may not be strictly in scope for us, I'd have no problem having us register JWA names for the common hash functions (e.g., "S256") so people could use them in this context.  Unless I hear objections, I'll proceed on this basis.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, November 04, 2013 11:36 AM
To: Mike Jones; 'Jim Schaad'
Cc: [email-masked]
Subject: RE: [jose] issue #25 TEXT

The only problem that I have with the text in the last paragraph is that it does not discuss where and how the hash algorithm is registered so that each application does not create its own registry of hash algorithms but uses a common one.  This could be done by having a new document that defines a body type for this and point, but that is a new document that would need to be written and discussed.

I also don't care for the second sentence.  The assumption is that the recipient can create the exact payload rather than has access to it.  For example adding the base64 wrapping is not an issue in terms of re-creating the content.

Jim

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, November 04, 2013 10:34 AM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] issue #25 TEXT

8.  Detached Content

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, September 29, 2013 1:08 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: issue #25 TEXT

Jim

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Nov 2013 16:03:08 -0800

Here's an objection.   :)

There is absolutely no reason to have two options for this.  We should just
have the "delete the payload" option, so that there's a single, consistent
technique for implementers.

In fact, the "sign a digest" option is not actually a detached signature --
it's an "attached" signature over the digest.

On Mon, Nov 4, 2013 at 11:54 AM, Mike Jones <[email-masked]>wrote:

>  While defining the hash function names may not be strictly in scope for
> us, I’d have no problem having us register JWA names for the common hash
> functions (e.g., “S256”) so people could use them in this context.  Unless
> I hear objections, I’ll proceed on this basis.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Monday, November 04, 2013 11:36 AM
> *To:* Mike Jones; 'Jim Schaad'
> *Cc:* [email-masked]
> *Subject:* RE: [jose] issue #25 TEXT
>
>
>
> The only problem that I have with the text in the last paragraph is that
> it does not discuss where and how the hash algorithm is registered so that
> each application does not create its own registry of hash algorithms but
> uses a common one.  This could be done by having a new document that
> defines a body type for this and point, but that is a new document that
> would need to be written and discussed.
>
>
>
> I also don’t care for the second sentence.  The assumption is that the
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Mike Jones
> *Sent:* Monday, November 04, 2013 10:34 AM
> *To:* Jim Schaad
> *Cc:* [email-masked]
> *Subject:* Re: [jose] issue #25 TEXT
>
>
>
> In some contexts, it is useful integrity protect content that is not
> itself contained in a JWS object.  There are two suggested ways of
> accomplishing this using JWS objects.
>
>
>
> One way is create a JWS object containing the payload in the normal
> fashion, but then delete the payload representation, and send this modified
> object to the recipient, rather than the JWS.  This method assumes that the
> recipient has access to the exact payload used in the JWS.  When using the
> JWS Compact Serialization, the deletion is accomplished by replacing the
> second field (which contains BASE64URL(JWS Payload)) value with the empty
> string; when using the JWS JSON Serialization, the deletion is accomplished
> by deleting the “payload” member.  To use the modified object, the
> recipient reconstructs the JWS by re-inserting the payload representation
> into the modified object, and uses the resulting JWS in the usual manner.
> Note that this method needs no support from JWS libraries, as applications
> can use this method by modifying the inputs and outputs of standard JWS
> libraries.
>
>
>
> *From:* Jim Schaad [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Sunday, September 29, 2013 1:08 PM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *Subject:* issue #25 TEXT
>
>
>
> Applications can do detached content with the JSON serialization.
>  Detached content has the benefit of allowing the content to be transmitted
> in a more natural format, and to avoid the expansion associated with
> applying the base64 transformation.  It has the downside that how the
> content is serialized into a text string is not preserved and therefore
> some type of canonicalization process may need to be applied by both the
> sender and the recipient.  In some circumstances this is not an issue
> (signing a binary file), while in other circumstances it can be problematic
> (end of line characters or ordering of JSON objects).  Applications cannot
> rely on this feature to be implemented by libraries but need to do it
> themselves.
>
>
>
> where it is transferred, applies the necessary canonicalization and
> encoding to it before creating the “payload” member of the JSON structure
> and passing the resulting object to the library for processing.
>
>
>
>
>
> Applications can do detached content with the JSON serialization.
> Detached content has the benefit of allowing the content to be transmitted
> in a more natural format, and to avoid the expansion associated with
> applying the base64 transformation.  Since the output of the encryption
> process is always an octet string, there are no canonicalization issues
> associated with transporting the encrypted string separately from the
> encryption header.
>
>
>
> On serialization, the application removes the “ciphertext” field from the
> JSON structure before writing it out.  The contents of the “ciphertext”
> “ciphertext” member of the JWE JSON structure.  The resulting object is
> then passed to the JOSE library for process.
>
>
>
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>