I agree that we should work on moving the docs to completion. I just submitted a set of issues that I've been collecting for a little while, meaning to submit.
Given that we're free to combine use documents, I guess I'll let most of the below slide. For the deliverables I thought should be combined, I will propose some ways forward in the next few days. Chairs: I would like to request a consensus call on whether we should take the following two actions: (1) Update item 4 in the charter to remove the string ", including mandatory-to-implement algorithms", and (2) Update draft-ietf-jose-json-web-algorithms to remove requirements levels (namely, the "Implementation Requirements" columns) --Richard On Jan 18, 2013, at 4:39 PM, Mike Jones <[email protected]> wrote: > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
