Proposal: Define a header field named "!". Its value is a string. A sender MUST include a "!" field in every JOSE message. A receiver MUST reject a JOSE message if the value of the "!" field is not recognized. The value of the "!" field defines the meaning of the message, including which other fields MUST be understood to correctly interpret the message in a fail-safe manner. Any other fields that the receiver does not recognize MUST be ignored. It is RECOMMENDED that receivers log the name of an unrecognized field the first time they see it as it is likely to provide a hint as to how the receiver could be improved (including being made more secure).
By making the "!" field define the meaning of the message, the obvious & easy implementation choice for a receiver is to switch to appropriate handling code based on the "!" value. Implementing the "MUST understand" rule for the "!" value occurs naturally as part of such switching. Consequently, senders can be confident that this "MUST understand" rule will be enforced by legitimate receivers. [In contrast, an alternative rule to reject messages with any unrecognized fields requires receivers to write extra code to filter out all known fields and see what remains. That extra code offers no extra functionality to the receiver; it is not needed for the receiver to process a message. Consequently, senders can have little confidence that such a "MUST understand" rule will be consistently enforced.] On defining a new form of JOSE message, a new value for the "!" field MUST be chosen if the message could be misinterpreted if it used an existing "!" value. (Example) initial values for the "!" field: "!":"sig" = the JOSE message contains a digital signature over the content using an asymmetric algorithm. The "alg" field MUST be understood. ... "!":"enc" = the JOSE message uses a known symmetric key with an AEAD algorithm to encrypt the content. The content may first be compressed. The "enc" and "zip" fields MUST be understood. ... "!":"env" = the JOSE message contains contents encrypted with an AEAD algorithm using a randomly-chosen per-message key that is conveyed to the receiver using an asymmetric key transport algorithm, or an asymmetric key agreement algorithm combined with a symmetric key wrapping algorithm. The content may first be compressed. The "enc", "trp", "agr", "wrp", and "zip" fields MUST be understood. ... Later "!":"env2" = as per "env" but supporting identity-based encryption (IBE) or a symmetric master key or ephemeral public keys for key exchange. The "ibe"... fields MUST be understood, in addition to the fields listed for "env". -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
