> On Aug 8, 2024, at 12:18 PM, Orie Steele <[email protected]> wrote:
>
> That's fair : )
>
> Let's replace "suspicion" with "I would have argued for a different design".
>
> In JOSE, ~ is just used as a placeholder for "missing unprotected header".
A tilde has two meanings in JWP, neither of which universally map to
unprotected headers. Since algorithms have a certain amount of flexibility
within their layering, I suppose they could potentially map into something like
countersignatures in individual cases.
>
> You still need to validate that the correct mutable data was included, and
> that no "unexpected mutable data" was included.
>
> That's a "verifier policy over mutable data".
>
> In the context of SD-JWT that means checking disclosures, matching their hash
> to the kbt and making sure the kbt is signed by the cnf.
In SD-JWT, my interpretation is that the use of a custom compact encoding is
far more powerful than unprotected headers as it actually provides requirements
and guidance on use due to imposing a specific, non-compatible structure. There
are edge cases for SD-JWT where the preprocessor MUST be used for claims to
otherwise be conformant to their own requirements (such as redacted members of
an array).
There is also no appropriate “must understand” at the JOSE level for things
like the key binding JWT or the disclosures. From a layering perspective, it is
unfortunate from a layering perspective that we are pushing requirements to
understand certain unprotected headers and payload preprocessing requirements
onto the payload content type - although that is also somewhat the original
point of SD-JWT.
I would argue that unprotected headers in JOSE have insufficient guidance
around correct usage by applications. Specifically, while the JOSE header is
the union or protected and unprotected parameters, there is no guidance on how
applications should deal with verification having non-integrity-protected
header values.
The security consideration around algorithm protection is the only place we get
close to mentioning that an implementation may need to specifically check that
some header parameters are within the protected header, and otherwise leaves
this to an application-level choice.
There is also this unfortunate text in RFC 7515, Section 4:
JOSE Header
For a JWS, the members of the JSON object(s) representing the JOSE
Header describe the digital signature or MAC applied to the JWS
Protected Header and the JWS Payload and optionally additional
properties of the JWS. The Header Parameter names within the JOSE
Header MUST be unique; JWS parsers MUST either reject JWSs with
duplicate Header Parameter names or use a JSON parser that returns
only the lexically last duplicate member name, as specified in
Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
Talking about duplicate parameter names at the JSON parser level in this
context misleads implementers to think that this is talking about duplicates
within a protected header or a unprotected header, not duplicates across the
two while performing a union to get the JOSE Header. Conversely, applying the
“lexically last duplicate” parser call-out might even imply that the
unprotected header parameters would acceptably take precedence over the
protected header parameters during this union.
(FWIW, COSE defines this collision as a SHOULD, but does indicate a required
preference from the protected bucket. It also indicates alg MUST be
authenticated, except in the non-enumerated cases where it can't be. Some
headers have call outs that that they are appropriate to be in an unprotected
header or that they should be in a protected header, but I would not call it a
consistent requirement for header definition)
<snip>
> Isn't JWP meant to replace SD-JWT in some cases that require stronger
> unlinkability?
> IIRC SD-JWT and OAUTH had good reasons to define a JSON Serialization, and if
> it's used, those users should be able to switch to JWP or CWP in the future.
Since JWP involves distinct headers from multiple parties (and interpretation
of these headers potentially by multiple parties), and also has a stronger need
for privacy considerations, I would expect far more definition would be needed
for unprotected headers in JWP than was present in JWS/JWE or COSE.
Proofs are also iMHO more likely to be involved in a protocol rather than to
protect documents/data at rest, due to being generated in response to a
particular request. (The expired
https://datatracker.ietf.org/doc/html/draft-waite-jws-multi-payload-00 was
partially meant to bridge that gap (to allow for applications defining their
data as multiple payloads to have a compatible, non-proof mechanism for
representation, but I didn’t perceive any traction around that document and
have so-far abandoned the effort.)
If a JWP is being transferred in the context of a protocol, there are plenty of
other mechanisms to convey additional unprotected data, without the need to
define processing rules or privacy considerations for these within JWP.
For those reasons, I’ve been more interested in entertaining specific
functionality carve-outs when proposed as part of JWP, rather than a catch-all
like unprotected headers.
-DW
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
