[jose] FW: issue #25 TEXT

"Jim Schaad" <ietf@augustcellars.com> Mon, 07 October 2013 23:07 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E421E80CF for <jose@ietfa.amsl.com>; Mon, 7 Oct 2013 16:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Level:
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoUqtK9mXAHu for <jose@ietfa.amsl.com>; Mon, 7 Oct 2013 16:07:41 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E50EE21E80CA for <jose@ietf.org>; Mon, 7 Oct 2013 16:07:40 -0700 (PDT)
Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 339AF38F25 for <jose@ietf.org>; Mon, 7 Oct 2013 16:07:40 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: jose@ietf.org
References:
In-Reply-To:
Date: Mon, 07 Oct 2013 16:06:23 -0700
Message-ID: <036601cec3b1$d97dc890$8c7959b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0367_01CEC377.2D205020"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac67uYs2YQOzlCuxQ0OV0iQkGne2gQH+Eo7Q
Content-Language: en-us
Subject: [jose] FW: issue #25 TEXT
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 23:07:46 -0000

 

 

From: Jim Schaad [mailto:ietf@augutscellars.com] 
Sent: Sunday, September 29, 2013 1:08 PM
To: Mike Jones (Michael.Jones@microsoft.com)
Cc: jose@ietf.org
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.