On Jan 18, 2013, at 8:21 AM, Richard Barnes wrote: > Inline > > >> ----- >> On 1,2,3,5,6: >> >> Do I understand correctly that milestones 5 and 6 are intended to be >> something like the JSON serialization documents, whereas 1, 2, and 3 are >> supposed to be something like the current documents? If that's the case, >> then we might as well call a spade a spade and remove "JSON-structured" from >> 1, 2, and 3. >> >> I find that sort of back-tracking pretty distasteful, though. As I've said >> before, it would be better if we could come up with a reasonable JSON syntax >> that would profile down to something compact and URL-safe. >> >> Yes, (1), (2), (3) (and (4)) are the deliverables in the present charter >> (http://datatracker.ietf.org/wg/jose/charter/). The “JSON-structured” >> wording is from the current charter. I suppose it could be changed to >> “JSON-based” if people prefer that. But minimizing changes to the existing >> charter items also seems like a good goal. I’d be fine with either the >> “JSON-structured” wording from the current charter or “JSON-based”. >> >> And yes, (5) and (6) are the JSON serialization documents, which we decided >> adopt as working group documents and create charter items for at the working >> group meeting in Atlanta. Consensus to do this is recorded at >> http://www.ietf.org/proceedings/85/minutes/minutes-85-jose. See >> http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 >> andhttp://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04 for >> the current versions of these documents. > > I just don't see any reason for us to have separate documents for a "JSON > serialization". It's what we should have done in the first place -- make > something "JSON-structured". Rather than having separate > documents/milestones, let's just put the JSON stuff in the base spec. It > will help ensure coherence between the formats, and it's really not that much > text. > > If we make the explicit decision not to include a JSON format in our base > deliverables, then we should just strike "JSON" altogether. JW* is as much > "ASN.1-based" as it is "JSON-based" -- it contains base64-serialized objects > of both types. > > >> On 4: >> >> This group has agreed time and again that we will not have mandatory to >> implement algorithms. As Mr. Housley put it, according to the IETF 85 >> minutes, "Each app defines MTI, achieving separation of MTI from syntax.". >> So the phrase "including mandatory-to-implement algorithms" needs to be >> struck from item (4). >> >> This statement makes no sense, as our current charter already *requires* us >> to produce “A Standards Track document specifying mandatory-to-implement >> algorithms for the other three documents”. The rechartering is about adding >> the new deliverables 5-8 – not changing our existing deliverables, of which >> this is one already one. > > You want to deviate from the first three milestones, I want to deviate from > this one :) > > There have been clear consensus calls at the last few IETF meetings that run > against this milestone. If the chairs would like to have an explicit call on > removing "mandatory to implement" from this milestone, then I would support > that. > > >> On 7,8: >> >> I have no idea what milestones 7 and 8 are supposed to entail. JWE already >> has wrapped keys, and JWS should (for MAC). As above, we should strive to >> get this right the first time instead of doing something halfway with a >> promise to patch it later. >> >> I’m surprised that you say that don’t understand 7 and 8, as you were in the >> Friday morning meeting in Atlanta that was organized by Joe Hildebrand and >> Jim Schaad that defined them. The minutes of that meeting are at >> http://www.ietf.org/mail-archive/web/jose/current/msg01337.html. >> Deliverable (A) in the minutes is charter item (7). Deliverable (B) in the >> minutes is charter item (8). >> >> (7) extends (3) to define JSON representations for private and symmetric >> keys (whereas (3) only defines representations for public keys). See >> http://tools.ietf.org/html/draft-jones-jose-json-private-and-symmetric-key-00 >> for a draft that does this. >> >> As we discussed at that meeting, while JWE uses wrapped key *values* >> (wrapped CMKs), this new document that Matt is writing will enable us to >> wrap both key values and associated key properties. It wraps a JWK >> representation (which per (7), may represent private and symmetric keys), >> including potential key properties as the key’s “alg” and “kid” values, as >> well as others that may be used. It’s intentionally more general than the >> wrapped CMK value used in JWE, again, as discussed during the Friday meeting >> in Atlanta. > > I was at that meeting, and I did not leave convinced that having a separate > document was the correct path, as opposed to doing wrapped keys right the > first time. > > JWE already has a mechanism for wrapping keys. Instead of inventing some > separate syntax, we should consolidate the "wrapped key" bits of JWE into an > object ("JSON Wrapped Key", or JWK :) ), and give that object a way to > protect attributes. If there are no attributes, then this just looks like > what's already in JWE. I can send a more thorough proposal to the list if you > like. > > In any case, I oppose adding these two milestones based on the above. If we > are going to handle this separately, then 7 and 8 should be combined, since > the format for symmetric/private keys will have to have a protection > mechanism.
Both the W3C WebCrypto and HTML media groups have use-cases for an unprotected representation of a symmetric key. In the WebCrypto case for export of such keys (where that is allowed according to the key properties) and for a representation that includes attributes which could then be wrapped (with AES Key Wrap, for example). In the HTML media group they would like to use this format for the "clearkey" key system for encrypted media, where the requirement is again just for a clear unprotected representation of the key and associated attributes. So (7) at least has stand-alone use-cases. …Mark > > --Richard > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
