Last Call Review of draft-ietf-jose-use-cases-05
review-ietf-jose-use-cases-05-secdir-lc-josefsson-2013-12-19-00

Hi.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes some places where signed/encrypted JSON
objects may be used, and gathers a list of requirements compiled from
those use-cases.  It is an Informational document, and doesn't mandate
any implementation requirements, but presumably may help to evaluate
whether the other JOSE deliverables meet expectations. The document is
well-writen, and quite entertaining to read as a survey of various
modern protocol use-cases. I only found minor issues.

MINOR ISSUES:

* The document is split into two parts, one that describes use-cases,
  and one that lists the requirements.  The text of the use-cases
  mention several requirements that the solution needs to have, however
  it is hard to map those to the requirements listed in the second
  part.  It is also hard to map the requirements back to the
  use-cases.  There is a risk that something mentioned in the use-case
  section is not reflected in the requirements, and vice versa.

  However since this is an informational document, and that it is
  intended to be read and parsed by humans rather than something that
  will be implemented, I don't think this is a serious problem.  For
  another approach, compare RFC 4226 which mix together a use case
  description with requirements.

NITS:

* Section 1 could mention PGP as well, it is a well known and widely
  used security protocol.

Section 2: The ordering is wrong.
OLD:
   In this document, we will refer to these as the "signed object
   format", the "encrypted object format", and the "key format",
   respectively.
NEW:
   In this document, we will refer to these as the "encrypted object
   format", the "signed object format", and the "key format",
   respectively.

Section 5.3: Typo
OLD:
   In the OpenID Connect context, and in some other applicaitions of
NEW:
   In the OpenID Connect context, and in some other applications of

Section 5.7: Cut'n'paste error
OLD:
      the counter value.  A custom Key Derivation Function (KDF)
      function is used when is based on the AES-CBC is used to derive
      the required MAC key.  The MAC key is then used to compute the MAC
NEW:
      the counter value.  A custom Key Derivation Function (KDF)
      function based on AES-CBC is used to derive
      the required MAC key.  The MAC key is then used to compute the MAC

/Simon