Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)
RFC 7520

Note: This ballot was opened for revision 07 and is now closed.

(Richard Barnes) Yes

Comment (2014-12-17 for -07)
No email
send info
Note: I have personally validated the examples in Sections 3.1, 3.3, 4.1, 4.2, and 4.3.  I used them in tests for a JWK/JWS library.  (The only difference between the text and the test case is that I had to add a "jwk" header field, because my code doesn't support lookup based on "kid".)


Now we just need RosettaCode entries for JOSE operations :)


Section 1.1.:

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

I think Barry commented on this in his pre-review, but it would be good to clarify this.  Perhaps you could describe the examples as a sequence of quoted strings, which the user should concatenate?  For example, in Section 4:

   "It\xe2\x80\x99s a dangerous business, Frodo, going out your "
   "door. You step onto the road, and if you don't keep your feet, "
   "there\xe2\x80\x99s no knowing where you might be swept off "

I agree with Alissa that "progenitor" is inapt.  "Private key corresponding to" is the typical phrasing.

(Kathleen Moriarty) Yes

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Comment (2014-12-17 for -07)
No email
send info
The authors engaged in the discussion with the OPS-DIR reviewer Jouni on the points below. Thanks

Few minor nits & comments:

o IDnits spits out warnings. I recon all of them are of kind that will be corrected by t he RFC Editor -> no worries.

o The document uses example domains "hobbiton.example" and alike. According to RFC2606 & 6761 the example domains are "example.com" etc. These should be corrected UNLESS they cause too much trouble regenerating outputs into examples...

o line 325 "coordiates" should probably be "coordinates".

o I would take acronyms (e.g. "(JWS)") away from the abstract.

Alissa Cooper No Objection

Comment (2014-12-15 for -07)
No email
send info
I would suggest using a simpler word than "progenitor" in 3.2 and 3.4 (unless it's a term of art, but it doesn't seem like it is).

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-12-17 for -07)
No email
send info

- 3.3, 1st para says private where it should say public

- thanks for addressing the (heroic:-) secdir review [1],
I think in the end you got everything rigth?

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05249.html

(Joel Jaeggli) No Objection

Comment (2014-12-18 for -07)
No email
send info
ok with the outcome of the opsdir review.

Barry Leiba No Objection

Comment (2014-12-13 for -07)
No email
send info
I've already made these comments by email, and discussed them with
Matt.  I'm quite satisfied that they're in hand, and no further response
is needed.

My experience is that any time there is a significant number of
examples, some of them will be wrong.  My experience is also that
readers will find those errors and will delight in filing errata
reports.  The shepherd writeup says that the compact encodings, at
least, have been checked for correctness, and I'm trusting that this
is adequate.  But please have pity on the Sec ADs and their
successors, who will have to deal with the inevitable errata, and
quadruple check things.  And make sure that errors are not introduced
during RFC Editor processing.  Do a more-careful-than-usual check
during AUTH48.

In particular, it is very importantant that the RFC Editor perform no
editing at all on the cleartext payloads.  For example:

   It\xe2\x80\x99s a dangerous business, Frodo, going out your
   door. You step onto the road, and if you don't keep your feet,
   there\xe2\x80\x99s no knowing where you might be swept off

If the RFC Editor's editing should double-space the sentences, your
examples based on the published cleartext would then be wrong.
Please make sure the the RFC Editor understands that they must
not alter that text in any way... and then please check that during AUTH48.

-- Appendix A --
Not that it matters terribly, but during AUTH48, you might coordinate
with the RFC Editor to make sure that single spacing (not double, as
now) is used after the periods in "J. R. R. Tolkien".  Kathleen might
put this into an RFC Editor note.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection