+1 to Richard's comments.
I havent been able to review the latest drafts (we will provide comments
from an internal review soon)
but I am very concerned about the embedding of complex application
semantics into headers defined by a signature/enryption specification.
- prateek
Of course, motherhood, apple pie, etc. :)
The question is what we're trying to help developers do. The
developers I talk to want a simple tool to do crypto stuff, full stop.
They don't want semantic validation, critical fields, etc.
The adoption you're pointing to is not really relevant to the process
here. The deployed implementations you're talking about are all in a
limited space, covering one use case. And the current solution comes
with baggage for that use case that adds complexity for everyone else.
If you wanted to address that one use case, you should have chartered
for that, not general signing and encryption.
Nonetheless, on timing, I agree that I'm getting a little bored with
fighting over this :) I'm working on a review of -11 that tries to
package up all the remaining comments such that they can get resolved
and we can move on with life.
--Richard
On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones
<[email protected] <mailto:[email protected]>> wrote:
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]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *Richard Barnes
*Sent:* Thursday, June 06, 2013 2:44 PM
*To:* [email protected] <mailto:[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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
