Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-07.txt

From: [email-masked]
Date: Wed, 07 Nov 2012 01:34:41 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Javascript Object Signing and Encryption Working Group of the IETF.

	Title           : JSON Web Encryption (JWE)
	Author(s)       : Michael B. Jones
                          Eric Rescorla
                          Joe Hildebrand
	Filename        : draft-ietf-jose-json-web-encryption-07.txt
	Pages           : 50
	Date            : 2012-11-07

Abstract:
   JSON Web Encryption (JWE) is a means of representing encrypted
   content using JavaScript Object Notation (JSON) data structures.
   Cryptographic algorithms and identifiers for use with this
   specification are described in the separate JSON Web Algorithms (JWA)
   specification.  Related digital signature and MAC capabilities are
   described in the separate JSON Web Signature (JWS) specification.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-json-web-encryption-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dick Hardt <[email-masked]>
Date: Wed, 7 Nov 2012 12:23:50 -0800

To enable encrypting and then signing of the same token, we need to specify the encrypting and signing algorithms separately.

Since we are using JSON, how about if we create an encryption object to contain all the parameters defined in JWE so that there is no overlap in the JWS namespace.

"enc": 
	{  "alg"
	,  "enc"
	,  "zip"
	}

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 9 Nov 2012 01:58:37 -0500

Hey Dick,

To make sure I understand your use case correctly: You want to convey an encrypted object, as well as a signature over the plaintext (without having to encrypt the signature value).  Does that sound accurate?

It seems like there are three types of information you want in the object: (1) cipher text, (2) encryption parameters, and (3) signature value/parameters.  So why not encapsulate it like that?  To propose a JSON syntax:

{
  "enc": { /* encryption parameters */ },
  "sig": { /* signature parameters + value */ },
  "val": "/* ciphertext */"
}

Obviously: 
-- JWE/JWS could be the special cases where only one of "enc" or "sig" is present
-- This cleanly supports multiple signatures via multiple "sig" values (e.g., in an array)
-- This cleanly supports multiple recipients via multiple "enc" values (e.g., in an array)
-- You could leave one of "enc" or "sig" parameters as flat lists (as in JWS/JWE), but it seems cleaner to have them parallel
-- For a compact serialization, you would want certain fields to be not double-base64'ed.  We can figure that out later :)

This seems like kind of an appealing line of reasoning to me.  I would be glad to do some work on figuring out the details.

--Richard

On Nov 7, 2012, at 3:23 PM, Dick Hardt <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Bob Wyman <[email-masked]>
Date: Fri, 9 Nov 2012 11:29:07 -0500

The "val" element in Barnes' proposal would need some parameters (typ, cty,
etc.) as well as the content in val:

{
  "enc": { /* encryption parameters */ },
  "sig": { /* signature parameters + value */ },
  "val": *{*/** content parameters +* plaintext */*}*
}

On Fri, Nov 9, 2012 at 1:58 AM, Richard L. Barnes <[email-masked]> wrote:

> Hey Dick,
>
> To make sure I understand your use case correctly: You want to convey an
> encrypted object, as well as a signature over the plaintext (without having
> to encrypt the signature value).  Does that sound accurate?
>
> It seems like there are three types of information you want in the object:
> (1) cipher text, (2) encryption parameters, and (3) signature
> value/parameters.  So why not encapsulate it like that?  To propose a JSON
> syntax:
>
> {
> -- You could leave one of "enc" or "sig" parameters as flat lists (as in
> JWS/JWE), but it seems cleaner to have them parallel
> -- For a compact serialization, you would want certain fields to be not
> double-base64'ed.  We can figure that out later :)
>
> This seems like kind of an appealing line of reasoning to me.  I would be
> glad to do some work on figuring out the details.
>
> --Richard
>
>
>
>
> > To enable encrypting and then signing of the same token, we need to
> specify the encrypting and signing algorithms separately.
> >
> > Since we are using JSON, how about if we create an encryption object to
> contain all the parameters defined in JWE so that there is no overlap in
> the JWS namespace.
> >
> > "enc":
> >       {  "alg"
> >       ,  "enc"
> >       ,  "zip"
> >       }
> >

---

From: Dick Hardt <[email-masked]>
Date: Tue, 13 Nov 2012 08:08:02 -0800

Bob / Richard

Including the signature value and the ciphertext in the JSON would needlessly enlarge the resulting token as it was base64url encoded.

Having the header use a hierarchical structure seems to make it easier to support multiple keys, which is needed if you want to sign and encrypt a message -- which seems to be a common use case!

-- Dick

On Nov 9, 2012, at 8:29 AM, Bob Wyman <[email-masked]> wrote:

> The "val" element in Barnes' proposal would need some parameters (typ, cty, etc.) as well as the content in val:
> 
> {
>   "val": {/* content parameters + plaintext */}
> }
> 
> 
>