Subject: [jose] I-D Action: draft-ietf-jose-use-cases-05.txt

From: [email-masked]
Date: Thu, 05 Sep 2013 08:47:42 -0700

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           : Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
	Author(s)       : Richard Barnes
	Filename        : draft-ietf-jose-use-cases-05.txt
	Pages           : 26
	Date            : 2013-09-05

Abstract:
   Many Internet applications have a need for object-based security
   mechanisms in addition to security mechanisms at the network layer or
   transport layer.  In the past, the Cryptographic Message Syntax (CMS)
   has provided a binary secure object format based on ASN.1.  Over
   time, the use of binary object encodings such as ASN.1 has been
   overtaken by text-based encodings, for example JavaScript Object
   Notation.  This document defines a set of use cases and requirements
   for a secure object format encoded using JavaScript Object Notation
   (JSON), drawn from a variety of application security mechanisms
   currently in development.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jose-use-cases

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-jose-use-cases-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-jose-use-cases-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 5 Sep 2013 11:53:05 -0400

This just updates the use cases to include a mention of non-protected
objects, as discussed previously on the list.
--Richard

On Thu, Sep 5, 2013 at 11:47 AM, <[email-masked]> wrote:

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Sep 2013 18:31:30 +0000

Thanks for getting this out, Richard.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, September 05, 2013 8:53 AM
To: [email-masked]
Subject: Re: [jose] I-D Action: draft-ietf-jose-use-cases-05.txt

This just updates the use cases to include a mention of non-protected objects, as discussed previously on the list.
--Richard

On Thu, Sep 5, 2013 at 11:47 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: Sean Turner <[email-masked]>
Date: Thu, 12 Sep 2013 20:16:14 -0400

I'm just nitting for now:

1) s2

OLD:

The JOSE working group charter calls for the group to define three basic 
JSON object formats:

NEW:

Three basic JSON object formats are initially defined, with more 
possibly defined later:

2) s2

OLD:

The JOSE working group items intended to describe these formats are JSON 
Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK), 
respectively [I-D.ietf-jose-json-web-signature] 
[I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-key].

NEW:

The JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web 
Key (JWK) specifications, respectively 
[I-D.ietf-jose-json-web-signature] [I-D.ietf-jose-json-web-encryption] 
[I-D.ietf-jose-json-web-key], define these formats.

3) s3: Not sure the following is entirely correct for DH-based algs:

  o  The JOSE encrypted object format must support object encryption in
     the case where the sender has only a public key for the receiver.

Shouldn't this also include the case where the sender has their own 
public key and the receiver's public key.

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 12 Sep 2013 18:04:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Turner
> Sent: Thursday, September 12, 2013 5:16 PM
> To: [email-masked]
JSON
> object formats:
> 
> NEW:
> 
> Three basic JSON object formats are initially defined, with more possibly
> defined later:
> 
> 2) s2
> 
> OLD:
> 
> Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key
> (JWK), respectively [I-D.ietf-jose-json-web-signature]
> Key (JWK) specifications, respectively [I-D.ietf-jose-json-web-signature]
[I-
> D.ietf-jose-json-web-encryption]
> Shouldn't this also include the case where the sender has their own public
> key and the receiver's public key.

Not really - we are doing ephemeral DH so the key sender key is created on
the fly.

Jim

---

From: Sean Turner <[email-masked]>
Date: Thu, 12 Sep 2013 22:13:59 -0400

> Not really - we are doing ephemeral DH so the key sender key is created on

Ah I should have re-read the alg draft too.

spt