Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
Note: This ballot was opened for revision 05 and is now closed.
(Jari Arkko) Yes
Comment (2013-12-17 for -05)
Thanks for a well written document.
(Sean Turner) Yes
(Stewart Bryant) No Objection
(Benoît Claise) No Objection
(Spencer Dawkins) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
Thanks for changing the reference to FIPS. The new text still isn't my favourite - I don't have that high an opinion of those kinds of evaluations in general - but I guess the WG won't go wild mimicing FIPS 140-2. --- old comments below, didn't check 'em but feel free to follow up if need be abstract: CMS isn't "in the past" suggest you make that present tense since this does not in any way OBSOLETE CMS. abstract: I'm also not sure that "overtaken" is right. Seems to me that these encoding schemes are fashion-items with an about 5 year "season" so being so definitive might look a bit silly next season. If you buy that, there'd maybe be other changes to make too. Generally, I don't think this needs to or should be doing a sales-pitch, and the same goes for the XML discussion too. intro: PGP is probably better "known" than S/MIME as a mail security solution. section 2: MAC == signing? Yuk. That does lead to developer confusion IMO. section 5: s/Several working groups/Several IETF working groups/ section 5: I thought Persona wasn't quite JOSE? Maybe I'm remembering wrong though (didn't check) typos: applicaitions, "JWT token" 5.4: What we use is OTR though. A ref to that would be good, just after you say that the CMS based approach hasn't been deployed. 5.7: This is a bit vague. I believe there are JOSE object that cannot be processed by the WebCrypto API and that there are WebCrypto algorithms that are not defined in JOSE, so API outputs cannot all be JOSE conformant. Is that correct? If so, then I think you need to say that for truth-in-advertising reasons. The fact that the WG think that's ok makes me sad. See also the secdir review  which calls out a few nits.  https://www.ietf.org/mail-archive/web/secdir/current/msg04481.html
(Joel Jaeggli) No Objection
Barry Leiba (was Discuss) No Objection
Comment (2013-12-19 for -05)
Given that the shepherd says, "it does not have sufficient apps area review," and "it needs more review outside of the group to make sure that the correct set of requirements has been setup for the solution," and given the questions we've raised about the interest in using the JOSE WG's product, it would have been good if the shepherd had done more to get App Area review -- perhaps more on apps-discuss (one of the chairs did post a note on 29 July), and by explicitly asking for Applications Directorate review (I'll talk with the appsdir team lead about watching for JOSE documents). Along with that, the document says, at the start of Section 5, "Several working groups developing application-layer protocols have expressed a desire to use the JOSE data formats in their designs for end-to-end security features." What are those working groups (the subsections indicate at least OAUTH, XMPP, ALTO, ATOCA, CORE, and W3C Web Crypto), and, apart from OAUTH, which is mentioned in the writeup, have the others of those reviewed this document? On to the document... A pet peeve of mine in the Introduction (you can play with my pets, or kick them aside, as you see fit): CMS is defined using Abstract Syntax Notation 1 (ASN.1) and traditionally encoded using the ASN.1 Distinguished Encoding Rules (DER) There are no traditions operating here. Perhaps you mean "typically", or "usually"? [Barry continues his review while whistling the opening tune from "Fiddler on the Roof"...] In addition to Stephen's comments about the abstract/introduction, with which I wholeheartedly agree (I would strongly prefer that you spin this as an alternative to CMS, not as a replacement): In practice, however, XML-based secure object formats introduce similar levels of complexity to ASN.1, so developers that lack the tools or motivation to handle ASN.1 aren't likely to use XML security either. Do you have anything to back this up with? It seems to me that whether I can cope with XML and whether I can cope with ASN.1 are two entirely separate things. Why on Earth should they be linked -- just because they're both complex? Section 3 begins with another of my pets: "Obviously," -- please, just say "no" to that, and remove the word (and the comma).