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
