crit was a relatively recent WG consensus that allowed for non critical header parameters by default.
Richard holds the unrelenting position that headers should not have integrity protection, and all header parameters should be optional unless defined otherwise in the core spec. I don't want to rehash the argument, but the compromise allowed for non critical to be the default and future extensions to use crit to mark parameters that need to be understood by the recipient to securely process the message. I understand the incremental edging towards the outcome you want, but endlessly revisiting consensus decisions will never allow us to finish. As to "typ" I agree that it's main use is by JWT where it is described. That is a result of splitting the specs into two workgroups. It is an optional field, we should clarify its definition so that JWT and other specs that need it have it available without potential namespace issues. That is what I thought WG decided. On the topic of changes the clock is running down for projects with dependencies on JOSE. At some point they will settle for what ever draft is current and ship based on that. That would be an interoperability tragedy. I have no control over what Mozzila and others decide, but at the moment we don't seem to be instilling the confidence in others that we are capable of moving the ball the last yard over the line (My attempt at a sports analogy). I agree with Axel and Mike on finishing. John B. On 2013-06-07, at 11:53 AM, <[email protected]> wrote: > +1 to Mike’s comments. > > Usefulness of the standard is the important thing. > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Mike > Jones > Sent: Friday, June 07, 2013 7:19 AM > To: Richard Barnes; [email protected] > Subject: Re: [jose] What are we doing here? > > Excellent question, Richard, because it gets to the heart of why the JOSE > specs are already highly successful and widely adopted. > > - We are building useful tools that solve real problems for developers. > - We are practically demonstrating the value of rough consensus and running > code. > - We are making simple things simple. > - We are making complex things possible, when necessary (but not at the > expense of keeping simple things simple). > - We are developing specs with an explicit goal of enabling ubiquitous > adoption. > - We are developing specs guided by practical engineering tradeoffs to > enable commonly useful functionality in a straightforward manner. > > The level of adoption, with dozens of deployed implementations, is compelling > evidence that we’ve already achieved the goals above. It’s time to “ship > it”, as making the JOSE specs actual standards will only increase their > adoption and value to the industry. > > That’s what we’re doing here. > > -- Mike > > P.S. I would be careful reasoning from the premise of “The perfect protocol > is one from which nothing can be removed”. By that logic, the perfect > specification is the null specification, which leaves all possibilities open, > and solves no actual problems. ;-) > > From: [email protected] [mailto:[email protected]] On Behalf Of > Richard Barnes > Sent: Thursday, June 06, 2013 2:44 PM > To: [email protected] > Subject: [jose] What are we doing here? > > The conversation about "typ" has brought us back to a familiar question for > this working group -- what are we trying to do here? > > The current document is ambiguous on this topic. On the one hand, it mostly > covers the crypto bases, with things like "alg" and "enc". On the other > hand, it mixes in application design concepts like "typ" and "crit". The > result is a spec that's ambiguous in purpose and complex. If I'm building an > application with this, how do I decide what goes in the "crit" field, or what > values to use for "typ"? > The charter for this working group is not ambiguous on this topic. This > group is chartered to do signing and encryption. The JOSE formats should > carry the parameters needed to perform those operations. Anything else is > extraneous, and in the spirit of "The perfect protocol is one from which > nothing can be removed", should be removed. > > Now, I'm not going to be a hard-liner on this. I won't complain about "zip" > and "cty", since they are clearly defined and have clear use cases. But > "crit" and "typ" are so ambiguous and so little supported by use cases*, that > they really should go. > > </rant> > > --Richard > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
