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 revision | 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 B. Jones , Erik Wahlstroem , Samuel Erdtman , Hannes Tschofenig | |
I-D last updated | 2018-03-08 | |
Completed reviews |
Secdir Telechat review of -12
by Kyle Rose
(diff)
Opsdir Telechat review of -12 by Carlos M. MartÃnez (diff) Genart Telechat review of -12 by Dan Romascanu (diff) |
|
Assignment | Reviewer | Kyle Rose |
State | Completed | |
Request | Telechat review on draft-ietf-ace-cbor-web-token by Security Area Directorate Assigned | |
Reviewed revision | 12 (document currently at 15) | |
Result | Has nits | |
Completed | 2018-03-08 |
review-ietf-ace-cbor-web-token-12-secdir-telechat-rose-2018-03-08-00
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.