Telechat Review of draft-ietf-ace-cbor-web-token-12

Request Review of draft-ietf-ace-cbor-web-token
Requested rev. no specific revision (document currently at 15)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2018-03-06
Requested 2018-02-15
Authors Michael Jones, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
Draft last updated 2018-03-08
Completed reviews Secdir Telechat review of -12 by Kyle Rose (diff)
Opsdir Telechat review of -12 by Carlos Martínez (diff)
Genart Telechat review of -12 by Dan Romascanu (diff)
Assignment Reviewer Kyle Rose
State Completed
Review review-ietf-ace-cbor-web-token-12-secdir-telechat-rose-2018-03-08
Reviewed rev. 12 (document currently at 15)
Review result Has Nits
Review completed: 2018-03-08


Reviewer: Kyle Rose
Review result: Ready with nits

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 draft specifies a means for representing claims in CBOR, and for using
COSE to encrypt and authenticate such claims. The listed security
considerations seem to cover the same ground as the respective slices of
the corresponding JWT references: the COSE RFC 8152 covers issues of trust
establishment, as well as the vagaries of signature algorithms and key
reuse, in more depth.

My only nit for this document is the repeated use of the phrasing "...has
the same meaning, syntax, and processing rules as..." throughout section
3.1: specifically, the inclusion of "syntax". For example, it doesn't seem
to make sense to talk about the syntax of a CBOR NumericDate being the same
as, or different from, the syntax of a JSON NumericDate: clearly, the
binary representation is different, and it's not at all clear that it makes
sense to talk about the human-readable source representation in this
context. That said, there is some parallelism with respect to StringOrURI,
as presumably the intent is to require that all strings containing a colon
also be valid URIs.