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