>From a process perspective, my recommendation would be for Web Crypto to >review the JOSE deliverables *before* they hit last call.
What would be a good time for that from the Jose WG's perspective? Thanks, -- Thomas Roessler, W3C <[email protected]> (@roessler) On 2013-01-23, at 12:18 +0100, Harry Halpin <[email protected]> wrote: > I'd just like to note that the W3C Web Crypto WG (of which Mike Jones is a > member) have been informally liasoning. However, as we enter Last Call we may > need to formalize this relationship more. > > I expect the Web Crypto WG to give a formal review of JOSE specs when they > hit Last Call. We probably don't need to sync charters (as that would delay > JOSE and we'd prefer JOSE to be stable *before* we hit Last Call), but we do > need to review and may need to ask for changes. If that is necessary to note > in the rechartering, please do so. > > And yes, its via discussions in the WebCrypto WG that the need for private > and symmetric key JOSE formats was brought up. Our spec is not in Last Call, > and thus our use of those is not yet set in stone, but it does seem like a > good idea to add them to the charter as we may need them. > > cheers, > harry > > > > On 01/11/2013 09:02 PM, Karen O'Donoghue wrote: >> Folks, >> >> Below is a draft update to our charter based on discussions at the last IETF >> meeting. The key changes are adding key representations and algorithm >> identifiers to the scope of work. This includes some minor language updates >> in the general section, the addition of deliverables 5-8, and the addition >> and modification of a number of milestones related to these documents. >> >> In addition, the phrase "using a compact URL-safe representation" has been >> added to the descriptions of the first two deliverables and "compact JSON >> object" used in the milestones. >> >> Jim and I will be submitting a revised charter shortly, and we would like >> your comments by 18 January if possible. >> >> Thanks, >> Karen >> >> >> Description of Working Group >> >> JavaScript Object Notation (JSON) is a text format for the serialization of >> structured data described in RFC 4627. The JSON format is often used for >> serializing and transmitting structured data over a network connection. >> With the increased usage of JSON in protocols in the IETF and elsewhere, >> there is now a desire to offer security services such as encryption, digital >> signatures, message authentication codes (MACs), and key representations for >> data that is being carried in JSON format. >> >> Different proposals for providing such security services have already been >> defined and implemented. This Working Group's task is to standardize four >> kinds of security services, integrity protection (signature and MAC), >> encryption, key representations, and algorithm identifiers, in order to >> increase interoperability of security features between protocols that use >> JSON. The Working Group will base its work on well-known message security >> primitives (e.g., CMS), and will solicit input from the rest of the IETF >> Security Area to be sure that the security functionality in the JSON format >> is correct. >> >> This group is chartered to work on eight documents: >> >> (1) A Standards Track document specifying how to apply JSON-structured >> integrity protection to data, including (but not limited to) JSON data >> structures, using a compact URL-safe representation. "Integrity protection" >> includes public-key digital signatures as well as symmetric-key MACs. >> >> (2) A Standards Track document specifying how to apply a JSON-structured >> encryption to data, including (but not limited to) JSON data structures, >> using a compact URL-safe representation. >> >> (3) A Standards Track document specifying how to encode public keys as >> JSON-structured objects. >> >> (4) A Standards Track document specifying algorithms and algorithm >> identifiers, including mandatory-to-implement algorithms for the previous >> three documents. >> >> (5) A Standards Track document specifying how to apply JSON-structured >> integrity protection to data, including (but not limited to) JSON data >> structures, using a JSON representation supporting multiple recipients. >> This document will build upon the concepts and structures in (1). >> >> (6) A Standards Track document specifying how to apply a JSON-structured >> encryption to data, including (but not limited to) JSON data structures, >> using a JSON representation supporting multiple recipients. This document >> will build upon the concepts and structures in (2). >> >> (7) A Standards Track document specifying how to encode private and >> symmetric keys as JSON-structured objects. This document will build upon >> the concepts and structures in (3). >> >> (8) A Standards Track application document specifying a means of protecting >> private and symmetric keys via encryption. This document will build upon >> the concepts and structures in (2) and (7). This document may register >> additional algorithms in registries defined by (4). >> >> The working group may decide to address combinations of these goals in >> consolidated document(s), in which case the concrete milestones for these >> goals will be satisfied by the consolidated document(s). >> >> Goals and Milestones >> >> Jan 2012 Submit compact JSON object integrity document (1) as a >> WG item. >> >> Jan 2012 Submit compact JSON object encryption document (2) as >> a WG item. >> >> Jan 2012 Submit JSON key format document (3) as a WG item. >> >> Jan 2012 Submit JSON algorithm document (4) as a WG item. >> >> Feb 2013 Start Working Group Last Call on compact JSON object >> integrity document (1). >> >> Feb 2013 Start Working Group Last Call on compact JSON object >> encryption document (2). >> >> Feb 2013 Start Working Group Last Call on JSON key format >> document (3). >> >> Feb 2013 Start Working Group Last Call on JSON algorithm >> document (4). >> >> Mar 2013 Submit JSON object integrity document (1) to IESG for >> consideration as Standards Track document. >> >> Mar 2013 Submit JSON object encryption document (2) to IESG for >> consideration as Standards Track document. >> >> Mar 2013 Submit JSON key format document (3) to IESG for >> consideration as Standards Track document. >> >> Mar 2013 Submit JSON algorithm document (4) to IESG for >> consideration as Standards Track document. >> >> Mar 2013 Submit multi-recipient JSON object integrity document >> (5) as a WG item. >> >> Mar 2013 Submit multi-recipient JSON object encryption document >> (6) as a WG item. >> >> Mar 2013 Submit JSON private and symmetric key document (7) as a >> WG item. >> >> Mar 2013 Submit JSON key protection application document (8) as >> a WG item. >> >> Jun 2013 Start Working Group Last Call on multi-recipient JSON >> object integrity document (5). >> >> Jun 2013 Start Working Group Last Call on multi-recipient JSON >> object encryption document (6). >> >> Jun 2013 Start Working Group Last Call on JSON private and >> symmetric key document (7). >> >> Jun 2013 Start Working Group Last Call on JSON key protection >> application document (8). >> >> Jul 2013 Submit multi-recipient JSON object integrity document >> (5) to IESG for consideration as Standards Track document. >> >> Jul 2013 Submit multi-recipient JSON object encryption >> document (6) to IESG for consideration as Standards Track document. >> >> Jul 2013 Submit JSON private and symmetric key document (7) to >> IESG for consideration as Standards Track document. >> >> Jul 2013 Submit JSON key protection application document (8) >> to IESG for consideration as Standards Track document. >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
