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