Hey Mark, >>> 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
Just to clarify: I certainly agree that need to solve the problem. I'm just not really convinced in needs a separate document (as opposed to an upgrade to JWK). Cheers, --Richard _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
