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

[Ballot comment]

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

[Ballot comment]
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).

[Ballot comment]
I won't have the time to review the full before the IESG telechat. I just spent 20 minutes on it.
Like Stephen, that sentence made we wonder:
  Over time, the use of binary object encodings such as ASN.1 has been
  overtaken by text-based encodings, for example JavaScript Object
  Notation.

I would like to get some OPS (SNMP/NETCONF) experts feedback on this draft regarding the ASN.1/XML statements, and state my position after that. For some statements, it's not clear if they apply only to applications, or also to protocols.
Most likely, with 2 DISCUSSes, this draft won't be approved today. So I have no intention to DEFER the draft.

[Ballot discuss]
Preamble:
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).

The DISCUSS point:
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?

[Ballot comment]
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).

[Ballot discuss]

6.2 says "do what FIPS says" more-or-less. I don't
think that should rise to this level of requirement.
The first sentence is fine, but the 2nd is not IMO.

[Ballot comment]


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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jose-use-cases-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)) to Informational RFC


The IESG has received a request from the Javascript Object Signing and
Encryption WG (jose) to consider the following document:
- 'Use Cases and Requirements for JSON Object Signing and Encryption
  (JOSE)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many Internet applications have a need for object-based security
  mechanisms in addition to security mechanisms at the network layer or
  transport layer.  In the past, the Cryptographic Message Syntax (CMS)
  has provided a binary secure object format based on ASN.1.  Over
  time, the use of binary object encodings such as ASN.1 has been
  overtaken by text-based encodings, for example JavaScript Object
  Notation.  This document defines a set of use cases and requirements
  for a secure object format encoded using JavaScript Object Notation
  (JSON), drawn from a variety of application security mechanisms
  currently in development.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-jose-use-cases/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-jose-use-cases/ballot/


No IPR declarations have been submitted directly on this I-D.