[jose] thoughts on header criticality from recent polls

[Karen O'Donoghue <[e-mail]>]

Folks,

Thank you for your patience with me regarding the recent polls on header 
criticality. I realize I have taken too long to respond from a chairs 
perspective with some results and direction. I had hoped to provide 
either a decision or a clear set of choices, but after analyzing the 
poll results, rereading all the email traffic (multiple times), and 
talking to a few working group members, I find I am not quite able to do 
so. So, what next...

First, what I do believe...

I think it is clear that the working group remains divided on this issue 
with a significant number of members feeling that an approach must be 
defined that safely allows for some header fields to be considered 
non-critical. I think there is general consensus that there must be 
reasonable mechanisms for extensibility, and that the approach must be 
generic. Based on that, I would like to ask the working group to move 
forward with the strategy that all headers cannot be considered critical 
and move on to the discussion of how to approach non-critical headers.

In my review of the mailing list traffic (and my apologies if I missed 
something), I have seen a number of basic approaches proposed 
(summarized by Jim Schaad on 9 Oct 2012 with the response by James 
Manager on 10 Oct 2012). In particular, I found James' list of 
requirements to be very helpful, and I have repeated it here...

A. Want to be able to define messages with new semantics in future, 
without any risk that old implementations will misinterpret them with 
old semantics.

B. Want to be able to *redefine* (or constrain) the semantics of 
*existing* fields in future, without any risk that old implementations 
will misinterpret them with old semantics (or without the constraints).

C. Want to prevent large blobs of ignored data appearing in messages, as 
similar blobs have been used to create hash collisions between 
legitimate & malicious certificates that use weak algorithms (eg MD5).

D. Want to strongly discourage future extensions (feature-creep), under 
the philosophy that even well-intentioned extensions tend to do more 
harm (by adding complexity that is only deployed sporadically) than the 
good of any new functionality they bring.

E. Loosely coupling clients and servers is generally considered a good 
thing; but strongly coupling them is more appropriate for a secure 
message format for [insert a reason here]. A possible reason is that 
people are too likely to choose to make an extension non-critical for 
short-term ease of interoperability, instead of making it critical for 
better long-term security.

 From this list, I believe A is definitely a requirement. I am unclear 
regarding working group consensus on B, C, and E, and I believe D is not 
a requirement.

QUESTION: Is there working group consensus on the requirements we are 
trying to address? Perhaps a short discussion clarifying these would 
help drive consensus on the overall approach.

As for possible solutions, we appear to have evolved to the point where 
we are of two minds:

1) Define a header field that explicitly lists the fields that may be 
safely ignored if not understood. (Here I am assuming that we aren't 
going to define a separate header for non-critical elements.)

2) Remain silent on header criticality in the JOSE specifications and 
leave it up to the various application specifications (possibly 
providing guidance directed to those applications in the JOSE specs).

I sense that there is more support for the first approach, but I am 
concerned that there is a significant minority that favor the second 
approach.

QUESTION: Can the working group agree on whether to work on approach 1 
or approach 2?

In conclusion, I am asking three things in this missive:
1. I am asking the working group to move forward based on a non-critical 
headers approach.
2. I am asking the working group to clarify the requirements driving the 
non-critical header discussion (A, B, C, D, E, or ?).
3. I am asking the working group to decide whether the right approach is 
to develop a specific syntax (if so, what?) or to defer to the 
applications with appropriate guidance (if so, what level of guidance)? 
To address this item, I welcome concise proposals of text.

I realize this message is long and not as specific or prescriptive as 
some would like, and I apologize in advance for any mistakes and 
misunderstandings on my part.

Regards,
Karen O'Donoghue