Subject: [jose] order of step for encryption. JWE section 5

From: <[email-masked]>
Date: Sun, 5 Aug 2012 08:54:31 +0200

Hi,

I have two issues with section 5 of
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html

1)
I would prefer it if the order of the steps 1 and 2 were reversed in section 5.

Currently we have:
Message Encryption

   The message encryption process is as follows.  The order of the steps
   is not significant in cases where there are no dependencies between
   the inputs and outputs of the steps.

   1.   When key agreement is employed, use the key agreement algorithm
        to compute the value of the agreed upon key.  When key agreement
        without key wrapping is employed, let the Content Master Key
        (CMK) be the agreed upon key.  When key agreement with key
        wrapping is employed, the agreed upon key will be used to wrap
        the CMK.

   2.   When key wrapping, key encryption, or key agreement with key
        wrapping are employed, generate a random Content Master Key
        (CMK).  See RFC 4086 [RFC4086] for considerations on generating
        random values.  The CMK MUST have a length equal to that of the
        larger of the required encryption and integrity keys.

Step 1 refers to the CMK that might be randomly created in step 2. I
think it is better to have the CMK generation
.

2) I find the text of the current step 1 confusing.
 2a) The first sentence is nearly a tautology
 2b) All sentences begin with When but the sentences two and three are
alternative choices and the first is not.
 2c) Does "When key agreement without key wrapping is employed, let
the Content Master Key
        (CMK) be the agreed upon key." make sense?
       What is the key agreement good for then?
       Should this read: "When key agreement without key wrapping is
employed, let the agreed upon key be the CMK" ? There SHOULD be some
randomness e.g. through the epk.

Could we structure these steps more? I) determine the CEK, generate
random values like IVs and epks II) build the jweHeaderSegment (e.g.
put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV)
build the jweCryptoSegment V) build the jweIntegritySegment VI)
base64url encode and concatenate the segments

---

From: Mike Jones <[email-masked]>
Date: Sun, 5 Aug 2012 12:20:06 +0000

Thanks for the careful read, Axel.  I'll work to make the write-up of the steps clearer, using your input.  In particular, I'll look for ways to better structure the steps.  (Unfortunately, the xml2rfc tool doesn't do a particularly good job of structuring lists with sub-lists.)

Answering your point 2c, a random CMK is not used in this case.  Instead, the agreed-upon key is used directly to perform the encryption.  I also plan to add a key agreement example in the next draft.  I expect that this will help make this case clearer.

				Thanks again,
				-- Mike
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, August 04, 2012 11:55 PM
To: [email-masked]
Subject: [jose] order of step for encryption. JWE section 5

Hi,

1)

Currently we have:
Message Encryption

Step 1 refers to the CMK that might be randomly created in step 2. I think it is better to have the CMK generation .

2) I find the text of the current step 1 confusing.
 2a) The first sentence is nearly a tautology
 2b) All sentences begin with When but the sentences two and three are alternative choices and the first is not.
 2c) Does "When key agreement without key wrapping is employed, let the Content Master Key
        (CMK) be the agreed upon key." make sense?
       What is the key agreement good for then?
       Should this read: "When key agreement without key wrapping is employed, let the agreed upon key be the CMK" ? There SHOULD be some randomness e.g. through the epk.

Could we structure these steps more? I) determine the CEK, generate random values like IVs and epks II) build the jweHeaderSegment (e.g.
put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) build the jweCryptoSegment V) build the jweIntegritySegment VI) base64url encode and concatenate the segments _______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: <[email-masked]>
Date: Sun, 5 Aug 2012 18:00:49 +0200

Maybe section 5 could have subsections like

5.1 Preparing Algorithm Parameters
determine the CEK, generate random values like IVs and epks
5.2  Building the jweHeaderSegment
 e.g put the IV randomly generated in 5.1 there
5.3 Building the jweKeySegment 
e.g. key wrapping
5.4 Building the jweCryptoSegment 
5.5 Building the jweIntegritySegment
5.6 Putting it all together
base64url encode and concatenate the segments

The subsections then could have list of steps or alternative lists of steps depending on header values

Axel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Sunday, August 05, 2012 2:20 PM
To: Nennker, Axel; [email-masked]
Subject: Re: [jose] order of step for encryption. JWE section 5

				Thanks again,
				-- Mike
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, August 04, 2012 11:55 PM
To: [email-masked]
Subject: [jose] order of step for encryption. JWE section 5

Hi,

1)

Currently we have:
Message Encryption

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 7 Aug 2012 12:00:36 -0700

Mike,

What is you issue of dealing with lists inside of lists for xml2rfc - is it
just a question of how things are formatted?  If so then this is an issue
that can be left to the RFC Editor.  Such formatting should be improved in
general over the next few months as the new version of xml2rfc processing
starts to get fully tested and rolled out.

If the problem is something else, I would be interested in hearing what it
is.

> Sent: Sunday, August 05, 2012 5:20 AM
> To: [email-masked]; [email-masked]
> Thanks for the careful read, Axel.  I'll work to make the write-up of the
steps
> clearer, using your input.  In particular, I'll look for ways to better
structure
> the steps.  (Unfortunately, the xml2rfc tool doesn't do a particularly
good job
> of structuring lists with sub-lists.)
> 
> Answering your point 2c, a random CMK is not used in this case.  Instead,
the
> agreed-upon key is used directly to perform the encryption.  I also plan
to
> add a key agreement example in the next draft.  I expect that this will
help
> make this case clearer.
> Step 1 refers to the CMK that might be randomly created in step 2. I think
it is
> better to have the CMK generation .
> 
build
> the jweCryptoSegment V) build the jweIntegritySegment VI) base64url
> encode and concatenate the segments

---

From: Mike Jones <[email-masked]>
Date: Mon, 20 Aug 2012 18:11:57 +0000

The problem is that sub-lists are formatted with the same indentation as the lists that enclose them.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2012 12:01 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] order of step for encryption. JWE section 5

Mike,

What is you issue of dealing with lists inside of lists for xml2rfc - is it just a question of how things are formatted?  If so then this is an issue that can be left to the RFC Editor.  Such formatting should be improved in general over the next few months as the new version of xml2rfc processing starts to get fully tested and rolled out.

If the problem is something else, I would be interested in hearing what it is.

steps
structure
good job
the
to
help
> think
it is
build