James, I think that is an interesting set of reasons. I would add the following to the list
F. Application developers and specification writes are unable to correct assess what is and is not important from the point of view of security. It is therefore better that the signature header fields are fully defined independent of any possible application specifications. While I disagree (in part) with the above statement for a number of reasons, I believe that there are number of people who would believe that it is a true statement. I agree that application developers and specification writers don't understand all of the implications, but I believe we can provide good guidance to them as part of this specficiation. Jim > -----Original Message----- > From: Manger, James H [mailto:[email protected]] > Sent: Wednesday, October 10, 2012 4:59 PM > To: Jim Schaad; [email protected] > Subject: RE: [jose] Criticality of Headers - Possible Answers > > Jim, > > Another possible solution: > > 5. One primary field is critical to understand. > [Ideally a field identifying the type of protection: > MACed, dig.sig., sym.encrypted, plain...] > The specification of each value of the primary > field indicates which other fields are critical > to understand when that primary value is present. > > > > More important than these 5 syntaxes for indicating criticality, however, is > agreeing on what we are trying to achieve with criticality. I don t think the > current drafts provide any clue. > > Possible requirements for making things critical: > > 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; KISS principle; version 1.0 is vastly more > important that any subsequent version. > > 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. > > F. ... > > > The MUST-understand-everything rule feels appropriate for E, maybe for D, > doesn't achieve C, and is (harmfully) far more draconian than necessary for B > or A. > I think JOSE should aim for requirement A. > > -- > James Manger > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Jim Schaad > > Sent: Wednesday, 10 October 2012 5:28 AM > > To: [email protected] > > Subject: [jose] Criticality of Headers - Possible Answers > > > > I am looking to establish the possible answers that we have for > > criticality of header fields and then want to follow it up with a > > discussion hopefully leading to closure. > > > > Please respond if I am missing any of the different solutions or if > > you think that I have all of the solutions that were discussed for the > > options. > > Also please feel free to augment the wording I have below on the > > description of the solution. I want to deal with pros and cons after > > we have the descriptions agreed on. > > > > 1. Any headers not covered by the current document generate an error. > > This > > is the current state of the document and is the all headers are > > critical solution. > > > > 2. Any headers not covered by the current document are ignored. This > > is the no headers are critical solution. > > > > 3. Headers are to be decorated in some manner to say if they are > > critical. > > There are four possible decoration methods that I have seen proposed. > > > > a) Change the field name to indicate it is critical (ala "SignTime!") > > b) Change the field name to indicate it can be ignored (ala > > "SignTime?") > > c) Create a header that has a list of either critical (or ignorable) > > field > > names > > d) Separate the non-critical header fields into a sub header > > > > 4. The core specification should ignore all issues of criticality and > > just define a common set of headers. It is up to the application to > > define which headers are critical, which can be ignored, and it can > > define new headers to meet it's needs. > > > > Jim > > > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
