> At IETF 84, I suggested that we take another look at what header
> information gets integrity-protected and what doesn't. The main issue
> being that in multiple-recipient or multiple-signer scenarios, there's
> unnecessary duplication of data if recipient- or signer-specific
> information is in the integrity-protected header.
The unnecessary duplication could be avoided while retaining full header
integrity protection if the JOSE syntax explicitly supported multiple
recipients/signers.
Richard’s JSMS draft, and Mike’s JWS-JS/JWE-JS drafts show that people want
specs for the multiple recipients/signers situations so I think we would be
better off supporting these cases in the core syntax from the start.
Multiple recipients/signers does add some complexity to the simplest (and
commonest) cases, but I suspect the change can be really quite minor for a
party that knows they only ever want to support a single recipient/signer. The
change basically just moves a few fields from a top-level JSON object to the
first JSON object in an array. Syntax overhead is 8 bytes, using "r" for
recipients.
FROM { ..., "x":123, "y":456, ... }
TO { ..., "r":[{"x":123, "y":456}], ... }
With support in the core for multiple recipients/signers, full integrity
protection would only cause duplication when multiple parties are added *at
separate times* (ie after a JOSE message has been created). The XMPP use case
did need this (Alice creates a JOSE message for Bob; later Bob’s server adds
Bob's phone and Bob’s laptop as new recipients), but that feels like quite a
specialized case that JOSE need not optimize for.
> Following some on what Bob Wyman proposed this afternoon, I would like
> to propose that we split the set of header fields into some logical
> groupings:
> 1. Top-level fields that require integrity protection (e.g., cty or a
> digest algorithm parameter)
> 2. Top-level fields that do not require integrity protection (e.g.,
> x5c)
> 3. Fields that are specific to a signer (e.g., jwk)
> 4. Fields that are specific to a recipient (e.g., epk)
Would another possibility for #2 be wrapping a JOSE message as the content of
another unprotected JOSE message that has the fields not requiring protection?
For example (without base64url-encoding for clarity):
{ "alg":"none", "x5c":["MIIE3…"], "ocsp":["MIeR…"]}.<inner-JOSE-message>.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
