> > > 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. -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
