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? 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
