If you have any changes or corrections, please get them to me soon. Thanks, Karen
JOSE WG @ IETF 90 2014-07-21 (1300-1500) The meeting was called to order by the co-chairs, Jim Schaad and Karen O�Donoghue. Peter Yee graciously agreed to take minutes. The note well was reviewed, and there were no proposed changes to the agenda. Agenda: https://www.ietf.org/proceedings/90/agenda/agenda-90-jose Chair slides: https://www.ietf.org/proceedings/90/slides/slides-90-jose-1.pdf 2. Open issues on four core documents (Chairs) draft-ietf-jose-json-web-algorithms-31 draft-ietf-jose-json-web-encryption-31 draft-ietf-jose-json-web-key-31 draft-ietf-jose-json-web-signature-31 All documents have been reviewed by Kathleen Moriarty (Security AD). There are two issues remaining: 1) the reference draft-mcgrew-aead-aes-cbc-hmac-sha2 instead of repeating text in the jose documents; and 2) the clarity of the wording: or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript] At this point the documents can go to last call, and we will resolve those remaining topics at that time. 3. Cookbook (Matt Miller) draft-ietf-jose-cookbook-03 Matt Miller updated the draft cookbook. Brian Campbell and others have done example verifications. Brian Campbell has also provided some text updates that Matt hasn�t had a chance to insert yet, but he will do so shortly (timeframe is tbd). Then the document will be ready for WGLC. 4. JSON Web Key Thumbprint (Mike Jones) draft-jones-jose-jwk-thumbprint-00 Slides: https://www.ietf.org/proceedings/90/slides/slides-90-jose-0.pdf Mike Jones presented his draft on JWK thumbprints. There has been a need identified for a thumbprint for keys that were in non-X.509 format. This wouldn�t be added to the current documents, but as an adjunct. The draft uses SHA-256 over JWK with required key fields in UTF-8 format, with fields placed in lexicographical order. Ordering of characters requiring escaping is the only tricky area � some sort of canonicalization would have to be done. Or the problem could be solved by not allowing the use of escaped characters in field names. Discussion: Carsten Bormann suggested the JSON WG could solve this problem. The JSON WG chair (Matt Miller) noted that this issue has been discussed before but there was insufficient energy to work on the problem and no consensus was forthcoming. Carsten Bormann believes that a single solution for all JSON-using WGs would be best, hence arguing for the JSON WG to solve it canonically. Mike Jones brought up the point that so far tag values are all ASCII and don�t run into the problem. Carsten Bormann likes a rule for canonicalization that says use the shortest representation and where there are case issues, always require upper case. A pointer to RFC 7159 would help somewhat. Phil Hunt says that the PRECIS WG has an algorithm that produces comparable strings. Mike Jones says we�ve been pretty clear that names should not be transformed for comparison. Matt Miller: bringing in PRECIS beyond what we�ve done with password transforms is not a good idea. Mike Jones: Security AD says that because no strings (except for passwords) are intended for human consumption, nor are they normally generated by human, we don�t have a real problem here. Jim Schaad: another solution: you could just omit anything that is escaped from your output, since the mapping isn�t guaranteed to be unique. Mike Jones: I prefer undefined representation (possibly to be defined later) than using that scheme. Matt Miller: that�s an interesting an idea. Or we could just use a whitelist � whatever is registered for a given key is acceptable, anything else is not. Jim Schaad: question: you�re using required fields from the JWK. That means you may be missing some of the constraints I might want to put on the JWK. Why isn�t that a problem? Mike Jones: this is just about identifying the key, not conveying all of the metadata values that may accompany the key. With the thumbprint, you should be able to retrieve the key and get all of those constraints. Jim Schaad: you might have two JWKs with the same key value but different constraints. Mike Jones: the CFRG says that using a key for two different algorithms/uses is not good hygiene. Matt Miller: limiting the thumbprint to very specific fields seems like a good idea to me. Mike Jones, continuing: can we add a charter item for this and move it into the WG? It would seem like something that could move through the WG very quickly. Jim Schaad: The chairs and AD need to verify whether this work is within the scope of the WG. Kathleen Moriarty: how many reviewers would there be? Miller is willing to do so. Lukewarm support from the WG for taking this on. Karen O�Donoghue: perhaps we should take this to the list. In any event, the chairs and Security AD will discuss it further. Mike Jones: I have received enough input to do another revision of the draft. Actions going forward: - Mike Jones will update the draft - The chairs will query the working group about taking up this work. 5. JOSE vs. Constrained Node Networks (Carsten Bormann) https://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf Carsten Bormann provided an introduction to CBOR. Moving from places, to people, to things, the expectation is for 50 billion nodes by 2020. Node size, cost, and complexity are all going down. Nodes are in the 10KB data, 100 KB code size (quite constrained) to the 50 KB data, 250 KB code size (not so constrained). Chip-level improvements are used to improve cost and power usage, not performance. These nodes use Low-power and lossy networks (LLN) of about 100 Kb/s bandwidth (at a high loss) and 100-byte packet size. The point is that these types of nodes require a recalibration of what we consider normal. Code, state, packet transmission, and listening are all �costly�. Crypto, by comparison to network usage, is almost negligibly expensive. The IETF already has many relevant WGs: LWIG, 6Lo*, 6TiSCH, ROLL, CoRE, DICE, and ACE. In improving the situation at the application layer, compressed HTTP is not a particularly viable solution � the gains aren�t sufficient. CoAP provides a more tailored solution, with simple headers and requests. CoAP is RESTful and can proxy to HTTP. Security is not optional for CoAP, which runs over DTLS 1.2 (and perhaps 6LoWPAN-GHC) at the 128-bit security level. ECC (P-256) is being embraced for its efficiency. The constrained node engineers have been considering suitable data formats. JSON was considered. Conside Binary Object Representation (sort of a binary JSON) uses the data model of JSON with binary representations for bit efficiency. CBOR is a fairly compact representation compared with other standardized formats. So, if CBOR is the answer, what about security for it? The thought is that JOSE could be adapted for CBOR. Requirements include dealing with very small payloads, minimization of power usage for transmission/reception, minimization of RAM usage, and simple code (owing to the lack of code space). Things to avoid: base64 and JSON-encoding of data. The �proposal� is COSE, in which each use of JOSE is replaced by a CBOR equivalent. Review and investigation are welcomed. Discussion: Mike Jones: would you use the registered algorithm names directly from JOSE? Bormann: we don�t want to re-invent anything, but it might be a good idea to assign numbers to those names as a more compact representation. Those things are third-order optimizations, however. Jones: Tim Bray has asked on the list if the benefits were sufficient to justify the work. Perhaps a side-by-side comparison would be useful. Bormann: Tim is probably from the Big Iron world where this is far less beneficial. In the constrained node world, CBOR is more impactful. Jones: the network-use minimization is a compelling argument. O�Donoghue: what are your plans? Bormann: we want to implement it in order to find out how well it works in practice. We also need to do a deep look at the security properties to determine if something breaks when switching to COSE from JOSE. Perhaps this WG or a new one would be the right place to standardize these efforts. Jones: the security efforts in JOSE should apply fine to COSE if it�s just a binary mapping being done. Many of those efforts were around delimited strings or making sure that concatenations didn�t have odd behaviors. Action: None at this time. Please report back on progress. Meeting adjourned: 14:00 EDT
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
