Re: [jose] draft revision to JOSE charter

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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> 