I'll observe that the primary purpose of the rechartering is to authorize additional work to occur within the JOSE working group. A secondary artifact of doing the restructuring is listing possible delivery vehicles for the outputs of the working group. I'll note that the rechartering text *explicitly allows* the working group to combine deliverables if it chooses to; it says "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)". So I would assert that arguments against the current rechartering text of the kind "deliverables X and Y should be combined" should not carry much weight, as the working group is free to make explicit decisions down the road to combine deliverables if it so sees fit.
Whereas, allowing them to be separate in the charter gives the working group more flexibility. Given that in Atlanta several working group members spoke up for keeping each of these deliverables separate, I don't think there's general agreement to combine them. Thus, moving forward with rechartering them as separate items let the work of the working group continue, while leaving open the possibility of combining deliverables, should there be consensus to do so. I believe we should proceed on that basis. Other working groups, including OAuth, W3C WebCrypto, and OpenID Connect are all depending upon us to produce our specifications in a timely fashion. We owe it to them and ourselves to continue making timely progress. Rechartering is necessary to enable the progress that they're counting on. Other comments inline in green... -----Original Message----- From: Richard Barnes [mailto:[email protected]] Sent: Friday, January 18, 2013 8:21 AM To: Mike Jones Cc: [email protected]; [email protected] Subject: Re: [jose] draft revision to JOSE charter 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. This is one of the places that you make the argument that we should block rechartering unless we combine deliverables. As already discussed, we already have the freedom to combine deliverables later, so this doesn't seem like a reasonable basis for not proceeding with the rechartering. 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. The reason that the original charter said "JSON-structured" rather than "JSON" was exactly to allow URL-safe representations (since JSON is not URL-safe). The header is represented as JSON object - hence meeting the JSON-structured criteria in the current charter. (Again, if you prefer "JSON-based" over "JSON-structured", I'm OK with that wording change, as is doesn't change the meaning of the text.) We *did* make an explicit decision to also include JSON representations in our output, Karen's consensus call for which is recorded in the Atlanta minutes. Hence, the need for deliverables (5) and (6). > 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 :) No, I don't want to deviate from the first three milestones. We already have working group drafts fulfilling them. 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. Those consensus calls have not occurred in this working group, nor do they apply to the output of this working group, to my knowledge. Decisions that may be right on one application context may not be the right ones in different application contexts. Nor do I think we should delay rechartering to possibly tweak this existing deliverable. We need the new work items to be able to make the progress that others are counting on us for. Further, I believe the IETF in general likes to have enough features be mandatory-to-implement such that interoperable implementations result. That's the reason for the existing charter language, as I understand it. > 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. I believe that this is another instance of you trying to make the argument that we should block rechartering unless we combine deliverables, which again, I believe isn't a valid reason not to proceed. 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. I'll note that you're expressing agreement with the need to define a wrapped key representation, so that means that you support us producing deliverable (8). The charter mostly is about "what". We can continue to refine "how" in the working group after the charter authorizes the work. 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. Again, given that the working group can combine deliverables if it sees fit, arguing not to enumerate those deliverables in the rechartering because they have not been combined doesn't seem like a reasonable position. --Richard Cheers, -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
