Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
draft-ietf-jose-use-cases-06

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).

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 [1] which calls out a
few nits.

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