Telechat Review of draft-ietf-ace-cbor-web-token-12
review-ietf-ace-cbor-web-token-12-secdir-telechat-rose-2018-03-08-00

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
Other Reviews Opsdir Telechat review of -12 by Carlos Martinez (diff)
Genart Telechat review of -12 by Dan Romascanu (diff)
Review State Completed
Reviewer Kyle Rose
Review review-ietf-ace-cbor-web-token-12-secdir-telechat-rose-2018-03-08
Posted at https://mailarchive.ietf.org/arch/msg/secdir/yVFGEMjFlY09rQ5YuziE1QZbiAI
Reviewed rev. 12 (document currently at 15)
Review result Has Nits
Draft last updated 2018-03-08
Review completed: 2018-03-08

Review
review-ietf-ace-cbor-web-token-12-secdir-telechat-rose-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.