Subject: Re: [jose] Working Group Last Call (WGLC) for draft-ietf-jose-cookbook-03

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Aug 2014 11:24:21 -0600

I have read this document generally believe it is close to being ready for
publication.

I have previously verified all the compact serialization examples in the
document and worked with Matt to work through and address discrepancies I
encountered. The verification was done using my open source JOSE
implementation, https://bitbucket.org/b_c/jose4j/wiki/Home, and is captured
in a series of unit tests, which can be seen here:
https://bitbucket.org/b_c/jose4j/src/869c51ac08cfc84c6cd8fa89fe9e271b332b01cd/src/test/java/org/jose4j/cookbook/JoseCookbookTest.java?at=master

My JOSE implementation only works with compact serialization and, as such,
I've not verified any of the JSON serializations in the cookbook. Although
the two serialization have a lot of commonality, It would probably be a
good idea to get an independent verification of the JSON serializations in
the document, if that hasn't happened already. And, of course, additional
verifications of all the examples wouldn't hurt either.

Lastly, I also had a couple of minor comments that I think would be good to
address prior to publication:
http://www.ietf.org/mail-archive/web/jose/current/msg04253.html
http://www.ietf.org/mail-archive/web/jose/current/msg04251.html

On Wed, Jul 23, 2014 at 8:41 AM, Karen ODonoghue <[email-masked]> wrote:

> Folks,
>
> This message starts a two week working group last call for the jose
> cookbook document "Examples of Protecting Content using JavaScript
> Object Signing and Encryption (JOSE)"
> (https://tools.ietf.org/html/draft-ietf-jose-cookbook-03)
>
> Please review the document and send comments, questions to the Working
> Group mailing list < jose at ietf.org > or the co-chairs <jose-chairs at
> tools.ietf.org > before the end of the WGLC.
>
> Please note that suggested changes which include proposed text will be
> more strongly considered than those without. Additionally, even if you
> have no comments, statements to the effect that "I have read this
> document and believe it is ready for publication" are helpful.
>
> Regards,
> Karen and Jim
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Aug 2014 01:21:48 +0000

COMMENTS ON NORMATIVE CONTENT

1.  This document contains a wealth of useful JWS and JWE examples using a broad selection of algorithms.  My review primary review comment is that it should also contain a section with illustrative JWK examples.  These examples should intentionally illustrate corner cases that will actually occur that developers might get wrong.  I would suggest adding these JWK examples:

1a.  JWK with "kty": "RSA", e=65537, and 2048 bit "n".  I would point out that neither can legally be prefixed by with extra zero bytes.  (Examples have been found in the wild in which developers mistakenly represent "n" values by encoding an extra leading byte - the extra byte being zero - rather than encoding the specified number of bytes - the highest-order bit of which is always 1 for a correctly generated key.  For instance, such mis-representations encode 257 bytes for a 2048 bit key, rather than 256 bytes.)

1b.  JWK with "kty": "EC", "crv": "P-256", and for which the high-order byte of one of "x" or "y" are zero.  I would point out that the high-order bytes are required to be represented, even if zero.  I would also point out that extra zero bytes are not permitted.

1c.  JWK with "kty": "EC", "crv": "P-521", and for which the high-order (521st) bit of one of "x" or "y" are zero (and because only one significant bit is used to represent the 521st bit in the high-order byte, consequently the corresponding high-order byte is zero).    I would point out that the high-order bytes are required to be represented, even if zero.  I would also point out that extra zero bytes are not permitted.

1d.  JWK with "kty": "oct" and 128 bit "k" value in which the high-order byte is zero.  I would point out that the high-order bytes are required to be represented, even if zero.  I would also point out that extra zero bytes are not permitted.

This will also necessitate revising some descriptive text at various locations in the specification.  For instance, a new sentence at the end of the Abstract should added "This document also illustrates a sampling of JSON Web Key (JWK) representations".

2.  Terminology usage throughout the document:  You should replace uses of the term "Protected JWS Header" with "JWS Protected Header", to match the JWS spec.  Likewise, you should replace "Protected JWE Header" with "JWE Protected Header", "Unprotected JW* Header" with "JW* Unprotected Header", etc.

The terms "JWS Header" and "JWE Header" were replaced with the term "JOSE Header" in the -29 versions.  You need to apply this change as well.

I'd likewise check other terms to make sure the ones you're using match the other JOSE specs.

3.  Section 3.1.2 (Signing Operation):  You show the JOSE header value as containing line breaks and whitespace, but the base64url encoded version of it does not contain these characters.  You need to say that the unencoded form is shown with extra whitespace for readability but that, for brevity, the cookbook omits these formatting characters that don't change the meaning of the JSON in the base64url encoded versions.  You should also say that they need not have been omitted, as they would have been legal in the base64url encoded JSON object.

I first noticed this inconsistency in Section 3, but it happens everywhere you display a JOSE Header value.  You probably need to say something general about this, as well as say something specific about it the first time it occurs in an example.

4.  Section 3.1.2 (Signing Operation):  You refer to the "combined projected JWS header and payload content".  It might be useful to readers to elaborate more on the combination.  You could, for instance, say that they are "combined ... into the JWS Signing Input value, as described in Section 5.1 of [JWS]".  I might do this for at least the first signing example.  At the very least, the term "JWS Signing Input" describing this intermediate result should probably appear somewhere.

5.  Section 3.1.3 (Output Results):  You show a result using the JWS Compact Serialization but with line breaks in it.  You need to say that the line breaks within the output value are for display purposes only.  For what it's worth, the JWS spec does this by including the phrases "(with line breaks for display purposes only)" or "(with line breaks within values for display purposes only)", where appropriate, in the description of the value.  This situation occurs throughout the specification.

6.  Section 3.1.3 (Output Results):  You show a result using the JWS JSON Serialization with line breaks within some values.  This would be an appropriate place to use the "(with line breaks within values for display purposes only)" language.  This situation occurs throughout the specification.

EDITORIAL COMMENTS

E0.  I would suggest taking the HTML output and running it through a grammar checker, such as the one in Microsoft Word.  This will catch a number of simple phrasing problems, omitted words, and repeated words.  Some specific editorial comments follow.

E1.  In the Abstract, the first "sentence" is missing a verb, and so is actually a fragment.  I'd change it to "This specification contains set of examples using JavaScript Object Signing and Encryption (JOSE) functionality to protect data".

E2.  In the Introduction, I would change the document order to JWS, JWE, JWK, JWA - as that is the standard order we usually talk about them in - in part, because if a developer uses only one of (JWS, JWE, and JWK), it tends to be JWS - so it makes sense to start with it.  JWA is last because it's used by all the others.  JWE follows JWS because it makes sense to group encryption with signing.  Which leaves JWK in the third spot.

E3.  In the Introduction, this sentence seems overly negative:  "The full set of permutations is extremely large, and might be daunting to some".  I'd reword it to: "While the full set of permutations is large, and might be daunting to some, it is expected that most applications will choose a relatively constrained set of algorithms and combinations that meet their needs".

E4.  Introduction: "compile together" -> "compile"

E5.  Section 1.1:  "enough factors" -> "enough information"

E6.  Section 1.1:  "or to validate or to validate" -> "or to validate"

E7.  Section 1.1: "some algorithms inherently use random data and cannot be exactly replicated" -> "some algorithms inherently use random data and therefore computations employing them cannot be exactly replicated"

E8.  In the Terminology section, use the document order JWS, JWE, JWK, JWA.

E9.  Section 3: "the sequence "\xe2\x80\x99" substituted" -> "the sequence "\xe2\x80\x99" is substituted"

E10.  Section 3: "line breaks (U+000A LINE FEED) replacing some " " (U+0020 SPACE)" -> "line breaks (U+000A LINE FEED) replace some instances of " " (U+0020 SPACE)"

E11.  Section 4:  Apply the same editorial corrections to the second paragraph as E9 and E10 above.

E12.  Acknowledgments: "quotes" -> "quotations"

E13.  Acknowledgments: Uses of ";" should be changed to ",".

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Karen ODonoghue
Sent: Wednesday, July 23, 2014 7:42 AM
To: [email-masked]
Subject: [jose] Working Group Last Call (WGLC) for draft-ietf-jose-cookbook-03

Folks,

This message starts a two week working group last call for the jose cookbook document "Examples of Protecting Content using JavaScript Object Signing and Encryption (JOSE)"

Please review the document and send comments, questions to the Working Group mailing list < jose at ietf.org > or the co-chairs <jose-chairs at tools.ietf.org > before the end of the WGLC.

Please note that suggested changes which include proposed text will be more strongly considered than those without. Additionally, even if you have no comments, statements to the effect that "I have read this document and believe it is ready for publication" are helpful.

Regards,

Karen and Jim

jose mailing list

[email-masked]<mailto:[email-masked]>

---

From: Matt Miller <[email-masked]>
Date: Wed, 6 Aug 2014 08:45:39 -0600

Thank you for your feedback, Mike.

More comments inline.

On 8/5/14, 7:21 PM, Mike Jones wrote:
> 1.  This document contains a wealth of useful JWS and JWE examples
> using a broad selection of algorithms.  My review primary review
> comment is that it should also contain a section with illustrative
> JWK examples. These examples should intentionally illustrate corner
> cases that will actually occur that developers might get wrong.  I
> would suggest adding these JWK examples:
> 
> 
> 
> 1a.  JWK with “kty”: “RSA”, e=65537, and 2048 bit “n”.  I would
> point out that neither can legally be prefixed by with extra zero
> bytes. (Examples have been found in the wild in which developers
> mistakenly represent “n” values by encoding an extra leading byte –
> the extra byte being zero – rather than encoding the specified
> number of bytes – the highest-order bit of which is always 1 for a
> correctly generated key. For instance, such mis-representations
> encode 257 bytes for a 2048 bit key, rather than 256 bytes.)
> 
> 
> 
> 1b.  JWK with “kty”: “EC”, “crv”: “P-256”, and for which the
> high-order byte of one of “x” or “y” are zero.  I would point out
> that the high-order bytes are required to be represented, even if
> zero.  I would also point out that extra zero bytes are not
> permitted.
> 
> 
> 
> 1c.  JWK with “kty”: “EC”, “crv”: “P-521”, and for which the
> high-order (521^st ) bit of one of “x” or “y” are zero (and because
> only one significant bit is used to represent the 521^st bit in the
> high-order byte, consequently the corresponding high-order byte is
> zero).    I would point out that the high-order bytes are required
> to be represented, even if zero.  I would also point out that extra
> zero bytes are not permitted.
> 
> 
> 
> 1d.  JWK with “kty”: “oct” and 128 bit “k” value in which the
> high-order byte is zero.  I would point out that the high-order
> bytes are required to be represented, even if zero.  I would also
> point out that extra zero bytes are not permitted.
> 
> 
> 
> This will also necessitate revising some descriptive text at
> various locations in the specification.  For instance, a new
> sentence at the end of the Abstract should added “This document
> also illustrates a sampling of JSON Web Key (JWK)
> representations”.
> 
> 

The document includes all of the above, but does not call them out
specifically.  I can add a section that copies a representative sample
of JWKs from elsewhere in the document.

> 
> 2.  Terminology usage throughout the document:  You should replace
> uses of the term “Protected JWS Header” with “JWS Protected
> Header”, to match the JWS spec.  Likewise, you should replace
> “Protected JWE Header” with “JWE Protected Header”, “Unprotected
> JW* Header” with “JW* Unprotected Header”, etc.
> 
> 
> 
> The terms “JWS Header” and “JWE Header” were replaced with the
> term “JOSE Header” in the -29 versions.  You need to apply this
> change as well.
> 
> 
> 
> I’d likewise check other terms to make sure the ones you’re using
> match the other JOSE specs.
> 
> 

I'll make the appropriate changes.  We better be done changing our
dictionary (-:

> 
> 3.  Section 3.1.2 (Signing Operation):  You show the JOSE header
> value as containing line breaks and whitespace, but the base64url
> encoded version of it does not contain these characters.  You need
> to say that the unencoded form is shown with extra whitespace for
> readability but that, for brevity, the cookbook omits these
> formatting characters that don’t change the meaning of the JSON in
> the base64url encoded versions. You should also say that they need
> not have been omitted, as they would have been legal in the
> base64url encoded JSON object.
> 
> 
> 
> I first noticed this inconsistency in Section 3, but it happens 
> everywhere you display a JOSE Header value.  You probably need to
> say something general about this, as well as say something specific
> about it the first time it occurs in an example.

Section 1.1 already contains the following paragraph:

All of the examples in this document have whitespace added to improve
formatting and readability. Except for JWE plaintext or JWS payload
content, whitespace is not part of the cryptographic operations.
Unless otherwise noted, the JWE plaintext or JWS payload content does
include “ “ (U+0020 SPACE) characters; line breaks (U+000A LINE FEED)
are added to improve readability but are not present in the JWE
plaintext or JWS payload.

Do you have a suggestion for better wording?  Does the working group
believe this needs to be repeated in very section?

> 
> 
> 
> 4.  Section 3.1.2 (Signing Operation):  You refer to the “combined 
> projected JWS header and payload content”.  It might be useful to 
> readers to elaborate more on the combination.  You could, for
> instance, say that they are “combined … into the JWS Signing Input
> value, as described in Section 5.1 of [JWS]”.  I might do this for
> at least the first signing example.  At the very least, the term
> “JWS Signing Input” describing this intermediate result should
> probably appear somewhere.
> 
> 

I can add the intermediate examples.

> 
> 5.  Section 3.1.3 (Output Results):  You show a result using the
> JWS Compact Serialization but with line breaks in it.  You need to
> say that the line breaks within the output value are for display
> purposes only. For what it’s worth, the JWS spec does this by
> including the phrases “(with line breaks for display purposes
> only)” or “(with line breaks within values for display purposes
> only)”, where appropriate, in the description of the value.  This
> situation occurs throughout the specification.
> 
> 

See above regarding Section 1.1.

> 
> 6.  Section 3.1.3 (Output Results):  You show a result using the
> JWS JSON Serialization with line breaks within some values.  This
> would be an appropriate place to use the “(with line breaks within
> values for display purposes only)” language.  This situation occurs
> throughout the specification.
> 

See above regarding Section 1.1.

> 
> 
> 
> 
> EDITORIAL COMMENTS
> 
> 
> 
> E0.  I would suggest taking the HTML output and running it through
> a grammar checker, such as the one in Microsoft Word.  This will
> catch a number of simple phrasing problems, omitted words, and
> repeated words. Some specific editorial comments follow.
> 
> 

I admittedly turned off my spell checkers once most of the examples
were in place due to the rather high signal-to-noise ratio.

> 
> E1.  In the Abstract, the first “sentence” is missing a verb, and
> so is actually a fragment.  I’d change it to “This specification
> contains set of examples using JavaScript Object Signing and
> Encryption (JOSE) functionality to protect data”.
> 
> 
> 
> E2.  In the Introduction, I would change the document order to JWS,
> JWE, JWK, JWA – as that is the standard order we usually talk about
> them in – in part, because if a developer uses only one of (JWS,
> JWE, and JWK), it tends to be JWS – so it makes sense to start with
> it.  JWA is last because it’s used by all the others.  JWE follows
> JWS because it makes sense to group encryption with signing.  Which
> leaves JWK in the third spot.
> 
> 
> 
> E3.  In the Introduction, this sentence seems overly negative:
> “The full set of permutations is extremely large, and might be
> daunting to some”.  I’d reword it to: “While the full set of
> permutations is large, and might be daunting to some, it is
> expected that most applications will choose a relatively
> constrained set of algorithms and combinations that meet their
> needs”.
> 
> 
> 
> E4.  Introduction: “compile together” -> “compile”
> 
> 
> 
> E5.  Section 1.1:  “enough factors” -> “enough information”
> 
> 
> 
> E6.  Section 1.1:  “or to validate or to validate” -> “or to
> validate”
> 
> 
> 
> E7.  Section 1.1: “some algorithms inherently use random data and
> cannot be exactly replicated” -> “some algorithms inherently use
> random data and therefore computations employing them cannot be
> exactly replicated”
> 
> 
> 
> E9.  Section 3: “the sequence “\xe2\x80\x99” substituted” -> “the 
> sequence “\xe2\x80\x99” is substituted”
> 
> 
> 
> E10.  Section 3: “line breaks (U+000A LINE FEED) replacing some “
> “ (U+0020 SPACE)” -> “line breaks (U+000A LINE FEED) replace some 
> instances of “ “ (U+0020 SPACE)”
> 
> 
> 
> E12.  Acknowledgments: “quotes” -> “quotations”
> 
> 
> 
> E13.  Acknowledgments: Uses of “;” should be changed to “,”.
> 
> 
> 
> 
> 
> -----Original Message----- From: jose
> [mailto:[email-masked]] On Behalf Of Karen ODonoghue Sent:
> Wednesday, July 23, 2014 7:42 AM To: [email-masked] Subject: [jose]
> Working Group Last Call (WGLC) for draft-ietf-jose-cookbook-03
> 
> 
> 
> Folks,
> 
> 
> 
> This message starts a two week working group last call for the
> jose cookbook document "Examples of Protecting Content using
> JavaScript Object Signing and Encryption (JOSE)"
> 
> Please review the document and send comments, questions to the
> Working Group mailing list < jose at ietf.org > or the co-chairs
> <jose-chairs at tools.ietf.org > before the end of the WGLC.
> 
> 
> 
> Please note that suggested changes which include proposed text will
> be more strongly considered than those without. Additionally, even
> if you have no comments, statements to the effect that "I have read
> this document and believe it is ready for publication" are
> helpful.
> 
> 
> 
> Regards,
> 
> Karen and Jim
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> 

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Aug 2014 17:53:55 +0000

Responses inline...

-----Original Message-----
From: Matt Miller [mailto:[email-masked]]
Sent: Wednesday, August 06, 2014 7:46 AM
To: Mike Jones; [email-masked]
Cc: Karen O'Donoghue
Subject: Re: [jose] Working Group Last Call (WGLC) for draft-ietf-jose-cookbook-03

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

More comments inline.

> comment is that it should also contain a section with illustrative JWK

> examples. These examples should intentionally illustrate corner cases

> that will actually occur that developers might get wrong.  I would

> suggest adding these JWK examples:

> 1a.  JWK with "kty": "RSA", e=65537, and 2048 bit "n".  I would point

> out that neither can legally be prefixed by with extra zero bytes.

> (Examples have been found in the wild in which developers mistakenly

> represent "n" values by encoding an extra leading byte - the extra

> byte being zero - rather than encoding the specified number of bytes -

> the highest-order bit of which is always 1 for a correctly generated

> key. For instance, such mis-representations encode 257 bytes for a

> 2048 bit key, rather than 256 bytes.)

> 1b.  JWK with "kty": "EC", "crv": "P-256", and for which the

> high-order byte of one of "x" or "y" are zero.  I would point out that

> the high-order bytes are required to be represented, even if zero.  I

> would also point out that extra zero bytes are not permitted.

> 1c.  JWK with "kty": "EC", "crv": "P-521", and for which the

> high-order (521^st ) bit of one of "x" or "y" are zero (and because

> 1d.  JWK with "kty": "oct" and 128 bit "k" value in which the

> high-order byte is zero.  I would point out that the high-order bytes

> are required to be represented, even if zero.  I would also point out

> that extra zero bytes are not permitted.

> This will also necessitate revising some descriptive text at various

> locations in the specification.  For instance, a new sentence at the

> end of the Abstract should added "This document also illustrates a

> sampling of JSON Web Key (JWK) representations".

The document includes all of the above, but does not call them out specifically.  I can add a section that copies a representative sample of JWKs from elsewhere in the document.

That would be good - thanks.  I would specifically call out the particulars like the high-order bit of one of the 521-bit values being zero, the high-order byte of one of the 256-bit values being zero, no extra leading zeroes being included for RSA "n" values, etc.  Particularly in the base64url encoding, most people won't know that AAAA represents a zero byte.

> uses of the term "Protected JWS Header" with "JWS Protected Header",

> to match the JWS spec.  Likewise, you should replace "Protected JWE

> Header" with "JWE Protected Header", "Unprotected

> JW* Header" with "JW* Unprotected Header", etc.

> The terms "JWS Header" and "JWE Header" were replaced with the term

> "JOSE Header" in the -29 versions.  You need to apply this change as

> well.

> I'd likewise check other terms to make sure the ones you're using

I'll make the appropriate changes.  We better be done changing our dictionary (-:

I sure hope so too! :)

> 3.  Section 3.1.2 (Signing Operation):  You show the JOSE header value

> as containing line breaks and whitespace, but the base64url encoded

> version of it does not contain these characters.  You need to say that

> the unencoded form is shown with extra whitespace for readability but

> that, for brevity, the cookbook omits these formatting characters that

> don't change the meaning of the JSON in the base64url encoded

> versions. You should also say that they need not have been omitted, as

> they would have been legal in the base64url encoded JSON object.

> everywhere you display a JOSE Header value.  You probably need to say

> something general about this, as well as say something specific about

> it the first time it occurs in an example.

All of the examples in this document have whitespace added to improve formatting and readability. Except for JWE plaintext or JWS payload content, whitespace is not part of the cryptographic operations.

Unless otherwise noted, the JWE plaintext or JWS payload content does include " " (U+0020 SPACE) characters; line breaks (U+000A LINE FEED) are added to improve readability but are not present in the JWE plaintext or JWS payload.

Do you have a suggestion for better wording?  Does the working group believe this needs to be repeated in very section?

I realized that the text in 1.1 was there but the problem is that many people use specs as a reference, rather than reading them cover-to-cover.  They'll skip what they consider to be boilerplate and go straight to the meat - the examples.

I don't know that people need to reminded in every example, but at a minimum, I'd remind them in the first example that the encoded JSON omits the whitespace shown in the displayed JSON.  And I'd remind them in the first example that the actual Compact Serialization doesn't include the whitespace shown.  You can do this with language like "As described in Section 1.1, ...".

> 4.  Section 3.1.2 (Signing Operation):  You refer to the "combined

> projected JWS header and payload content".  It might be useful to

> instance, say that they are "combined ... into the JWS Signing Input

> value, as described in Section 5.1 of [JWS]".  I might do this for at

> least the first signing example.  At the very least, the term "JWS

> Signing Input" describing this intermediate result should probably

> appear somewhere.

> 5.  Section 3.1.3 (Output Results):  You show a result using the JWS

> Compact Serialization but with line breaks in it.  You need to say

> that the line breaks within the output value are for display purposes

> only. For what it's worth, the JWS spec does this by including the

> phrases "(with line breaks for display purposes only)" or "(with line

> breaks within values for display purposes only)", where appropriate,

> in the description of the value.  This situation occurs throughout the

> specification.

> 6.  Section 3.1.3 (Output Results):  You show a result using the JWS

> JSON Serialization with line breaks within some values.  This would be

> an appropriate place to use the "(with line breaks within values for

> display purposes only)" language.  This situation occurs throughout

> the specification.

> E0.  I would suggest taking the HTML output and running it through a

> grammar checker, such as the one in Microsoft Word.  This will catch a

> number of simple phrasing problems, omitted words, and repeated words.

> Some specific editorial comments follow.

I admittedly turned off my spell checkers once most of the examples were in place due to the rather high signal-to-noise ratio.

I know - it's moderately painful.  It takes me about 20 minutes to do the full spelling and grammar check of the concatenated JWS, JWE, JWK, JWA, and JWT specs when I do a release.  Use the keyboard shortcuts Alt-i for ignore a single instance of a grammar problem and Alt-g to ignore all instances of a word that's legal in the document but not legal English - like "alg", etc.  That will speed things up.

I'd do all your other edits, then do this at least once.  I think you'll be surprised how much you find.  In my experience, the grammar checking is often even more important than the spelling checking.

> E1.  In the Abstract, the first "sentence" is missing a verb, and so

> is actually a fragment.  I'd change it to "This specification contains

> set of examples using JavaScript Object Signing and Encryption (JOSE)

> functionality to protect data".

> JWE, JWK, JWA - as that is the standard order we usually talk about

> them in - in part, because if a developer uses only one of (JWS, JWE,

> and JWK), it tends to be JWS - so it makes sense to start with it.

> JWA is last because it's used by all the others.  JWE follows JWS

> because it makes sense to group encryption with signing.  Which leaves

> JWK in the third spot.

> "The full set of permutations is extremely large, and might be

> daunting to some".  I'd reword it to: "While the full set of

> permutations is large, and might be daunting to some, it is expected

> that most applications will choose a relatively constrained set of

> algorithms and combinations that meet their needs".

> E7.  Section 1.1: "some algorithms inherently use random data and

> cannot be exactly replicated" -> "some algorithms inherently use

> exactly replicated"

> E8.  In the Terminology section, use the document order JWS, JWE, JWK,

> JWA.

> E9.  Section 3: "the sequence "\xe2\x80\x99" substituted" -> "the

> sequence "\xe2\x80\x99" is substituted"

> E10.  Section 3: "line breaks (U+000A LINE FEED) replacing some " "

> (U+0020 SPACE)" -> "line breaks (U+000A LINE FEED) replace some

> instances of " " (U+0020 SPACE)"

> E11.  Section 4:  Apply the same editorial corrections to the second

> paragraph as E9 and E10 above.

> Wednesday, July 23, 2014 7:42 AM To: [email-masked]<mailto:[email-masked]> Subject: [jose]

> Group mailing list < jose at ietf.org > or the co-chairs <jose-chairs

> at tools.ietf.org > before the end of the WGLC.

> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

- --

- - m&m

Matt Miller < [email-masked]<mailto:[email-masked]> >

Cisco Systems, Inc.

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Aug 2014 18:09:38 +0000

Minor correction to what I wrote below...  I wrote "most people won't know that AAAA represents a zero byte".  That's actually three zero bytes.  What I should have written was "most people won't know that AA through AP all represent a leading zero byte".

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, August 06, 2014 10:54 AM
To: Matt Miller; [email-masked]
Cc: Karen O'Donoghue
Subject: Re: [jose] Working Group Last Call (WGLC) for draft-ietf-jose-cookbook-03

Responses inline...

-----Original Message-----
From: Matt Miller [mailto:[email-masked]]
Sent: Wednesday, August 06, 2014 7:46 AM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Cc: Karen O'Donoghue
Subject: Re: [jose] Working Group Last Call (WGLC) for draft-ietf-jose-cookbook-03

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

More comments inline.

I sure hope so too! :)

- --

- - m&m

Cisco Systems, Inc.

---

From: Karen ODonoghue <[email-masked]>
Date: Wed, 6 Aug 2014 14:23:59 -0400

Just one quick question on the JWK examples section...
> < stuff deleted...>
> That would be good -- thanks.  I would specifically call out the
> particulars like the high-order bit of one of the 521-bit values being
> zero, the high-order byte of one of the 256-bit values being zero, no
> extra leading zeroes being included for RSA "n" values, etc. 
> Particularly in the base64url encoding, most people won't know that
> AAAA represents a zero byte.
>

I'm just wondering if you could create a section that had some
explanatory text and pointed to the relevant examples elsewhere instead
of duplicating them. Duplicating information makes me a bit nervous.
And, I wonder if it would be less work...

Just a thought, and I'm happy with whatever approach Matt is willing to
take given that he is doing the heavy lifting on this...

Karen

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 25 Aug 2014 09:21:27 -0700

I think that you should considering adding one more example to the document.
I would not consider the document as being unable to progress without this
example, I just think it would be a good example to have in the document.

The missing example in the document that I would like to see added would be
one to deal with a password that requires both processing into UTF8 as well
as some PRECIS processing. 

The PRECIS processing could be dealt with by having either some non-ASCII
space characters or having the step of doing some NFC normalization be
applied to the string before it is used as a password.  

I believe that this would be a good example to have in the document because
of the general bias of developers to be in the US and not understand these
types of I18N issues that need to be dealt with.

Jim

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Karen ODonoghue
Sent: Wednesday, July 23, 2014 7:42 AM
To: [email-masked]
Subject: [jose] Working Group Last Call (WGLC) for
draft-ietf-jose-cookbook-03

Folks,

This message starts a two week working group last call for the jose cookbook
document "Examples of Protecting Content using JavaScript Object Signing and
Encryption (JOSE)"
(https://tools.ietf.org/html/draft-ietf-jose-cookbook-03)

Please review the document and send comments, questions to the Working Group
mailing list < jose at ietf.org > or the co-chairs <jose-chairs at
tools.ietf.org > before the end of the WGLC. 

Please note that suggested changes which include proposed text will be more
strongly considered than those without. Additionally, even if you have no
comments, statements to the effect that "I have read this document and
believe it is ready for publication" are helpful.

Regards,
Karen and Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 25 Aug 2014 09:23:37 -0700

This closes the last call period on this document.

While Brian is right and it would be nice if there was a verification on the
non-compact form of the examples.  I don't believe that this is a blocker
for advancement.

I am not sure that I understand all of Mike's requests, but it appears that
Matt does so this should be able to be incorporated without any problems.

I believe that Matt should be able to issue a new version of the document
and we should be able to progress it to our AD for processing.

Jim

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Karen ODonoghue
Sent: Wednesday, July 23, 2014 7:42 AM
To: [email-masked]
Subject: [jose] Working Group Last Call (WGLC) for

Folks,

Regards,
Karen and Jim