Re: [jose] draft revision to JOSE charter

[Richard Barnes <[e-mail]>]

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