If they were truly non-critical and marked as critical then there was a decision process that arrived at the incorrect conclusion. There are several examples of critical extensions that if ignored will cause the processing of a certificate to lead to wide security problems. An example is name constraints.
On Thu, Jul 26, 2012 at 9:41 PM, Jim Schaad <[email protected]> wrote: > <personal> > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Manger, James H > > Sent: Thursday, July 26, 2012 8:45 PM > > To: Breno de Medeiros; [email protected] > > Subject: Re: [jose] MUST understand ALL header fields > > > > Breno, > > > > > Inevitably, a field will be added that shouldn't be ignored because it > > modifies the meaning of some other widely understood header entry, > > followed by usual antics and general perplexity. > > > > Is there a good example of where this has occurred? That might help us > > reach a common understanding. > > > > > > > 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 > > > > > P.S. If the 7 header parameters that are defined in JWS (draft 04) but > never > > used in its examples were all defined as "extensions", would any be > critical? > > jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it. > > > > > > > It is NOT sufficient to say MUST ignore non-understood fields in the > > header. This will make it impossible to write secure implementations of > > validation libraries in practice. > > > > CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields that > > can hold arbitrary attributes. I see no mention in those specs of a "MUST > > understand" rule for attributes in those fields. I haven't heard that > that has > > made it impossible to write secure implementations of validation > libraries. > > > > Is it OK for CMS because there are dedicated fields for the primary > items (eg > > signatureAlgorithm), separate from the authAttrs bucket? I don't think > that > > can be the difference. > > > > Lots of CMS attributes have been defined by different parties. For > instance, > > CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or mentions > > dozens (signer-location, content-hints, signing-certificate, > commitment-type, > > �). Some MUST be present in a CAdES message, others are OPTIONAL. From > > a quick glance I didn't see a statement about which MUST be understood. > > > > > > -- > > James Manger > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > -- --Breno
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
