The problem I have with this proposal is that it imposes a burden in the normal
case, where no extensions are used. Should the working group decide to allow
ANY not-understood fields (and only if), I would make this counter-proposal:
Define an "ext" (extras) header field, the value of which is an array of the
extra fields in the header that may be ignored. It would be illegal to include
any of the specification-defined fields in this array. So for example, a
header could then legally contain:
{"alg":"ES256",
"ext":["notes"],
"notes":"This signature need not be checked when the moon is full"
}
This counter-proposal would impose a space burden on implementations only when
extra that need not be understood are actually used.
Again, my personal preference would be to have no such mechanism, for exactly
the reasons that Breno and Axel have stated. But should the working group
decide to have one, we could use my counter-proposal above.
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Manger,
James H
Sent: Friday, July 27, 2012 12:20 AM
To: [email protected]
Subject: Re: [jose] MUST understand ALL header fields: "!" field
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
