> -----Original Message----- > From: Manger, James H [mailto:[email protected]] > Sent: Friday, July 27, 2012 12:31 AM > To: Jim Schaad; [email protected] > Subject: RE: [jose] MUST understand ALL header fields > > > > > An extension mechanism would define: > > > > > > > > - How to bundle fields of an extension as a single object. > > > > - How to indicate that this object is an extension, and whether > > > > the > > > extension is critical (can't be safely ignored) or not. > > > > If we support extensibility with per-extension criticality flags, > > > wouldn't it be almost as inevitable that an extension will be added > > > that shouldn't be ignored but is marked non-critical to not break > > > interop? Or do you think people will "do the right thing (not the > > > easy thing)" with criticality flags? > > > Anyone who believes this to be a true statement is more than welcome > > to read the current firestorm about name constraints on the PKIX > > mailing list. They were defined and said to be critical when the > > first draft > > (RFC2459) came out in 1999 and people are saying that they need to > > make it non-critical because too many people did not implement it. > > The JOSE documents are better in that there are not as many "extensions" > > defined. But the history is still there. > > > Jim, > > What is you conclusion for JOSE s "MUST understand everything" rule from > the critical name constraints firestorm? > > My conclusion is that the criticality of name constraints has prevented its > widescale deployment for a decade -- so internet security has suffered. A > "MUST understand everything" rule in JOSE will similarly freeze its > functionality, preventing security improvements.
My conclusion on the name constraints issues is that it was correctly defined as being critical by the specification; however nobody understood why they would ever need it so it was never implemented. This means that nobody today can roll out using the name criticality functionality that should have been there from the start. My personal opinion on the "MUST understand everything" rule is that we are looking at the wrong place for making this statement. The correct statement is really that a library implementing the JW* documents needs to return a set of fields that it either 1) used in processing the document or 2) would have used in processing the document and it is up to the application (i.e. JWT) to decide if any given field is either mandatory, optional or required to be present. This punts the problem from the process library which would not know how to deal with application specific items (i.e. the application would need to pass in a complete list of everything under the sun that it could possible permit being there) and moves it to where it makes sense - the application. This is the basic position that is espoused by the CMS documents. We can validate a signature and will use some items, but the rest are left up to the interpretation of the application for both what they mean and if they need to be there or need to be absent. The default being that one ignores what one does not care about for most applications but not all. Jim > > -- > James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
