[jose] Re: Do you need the JWP JSON Serialization?

[Orie Steele <[e-mail]>]

On Thu, Aug 8, 2024 at 3:26 PM Neil Madden <[e-mail]> wrote:

>
>
> On 8 Aug 2024, at 20:44, Orie Steele <[e-mail]> wrote:
>
> 
> That only applies to "SD-JWT+KB"
>
>
> I don’t think so, otherwise SD-JWT would not be secure. The signature
> covers the claims, which includes the hashes of all the disclosures. Thus
> the disclosures are all protected (cannot be altered/forged) and immutable.
>

In SD-JWT (without +KB) the Issuer's signature covers the claims which
include hashes of the disclosures, that is true.

The order of ~ separated stuff is not secured ... because that stuff is not
included in the claims.
There could also be extra stuff that appears to be disclosures, but is
actually not in the issuer SD-JWT.
See:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-5.3.1


>
> [..]
>
> Unless I am mistaken, there is no ordering requirement for the SD-JWT
> without key binding, so the disclosures are mutable, until the holder makes
> them immutable by applying key binding:
>
>
> They are an unordered set, so this “mutability” is irrelevant.
>

Exactly, they are unordered, and unsecured (they are outside of the JWT).

See
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-8.1

"""
If any digest value is encountered more than once in the Issuer-signed JWT
payload (directly or recursively via other Disclosures), the SD-JWT MUST be
rejected.
If any Disclosure was not referenced by digest value in the Issuer-signed
JWT (directly or recursively via other Disclosures), the SD-JWT MUST be
rejected.
"""

This means it is possible for an adversary to cause an SD-JWT without key
binding to be rejected, by dropping or adding properties... in between the
issuer and the holder, before the key binding token is even possible to
produce.

The only way to know if this is the case as a holder is to perform the
validation steps in 8.1 on the issuer signed SD-JWT (without KB) before
considering attempting to use it.
This property is ensured by: "The Holder or the Verifier MUST perform the
following (or equivalent) steps when receiving an SD-JWT..."

See:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-9.3

"""
In case of the General JSON Serialization, there are multiple unprotected
headers (one per signature). If present, disclosures and kb_jwt, MUST be
included in the first unprotected header and MUST NOT be present in any
following unprotected headers.
"""

In SD-JWT JSON Serialization, disclosures and kbt are transmitted in
unprotected headers... You need to process them carefully as described in
section 8.1, in order to be assured that they have not been tampered with.
In SD-JWT Compact serialization, disclosures and kbt are transmitted as
concatenated strings... You need to process them carefully as described in
section 8.1, in order to be assured that they have not been tampered with.

The major difference between these 2 approaches is that there is no ability
to include "other" unprotected material in the jwp compact serialization...
this property is unique to JOSE compact serializations, because they cannot
express unprotected headers.
COSE / CWP will not have this problem... assuming it follows conventions.

I think JOSE / JWP would be improved if support for unprotected headers was
consistent in both compact and json.



>
> […]
>
>
> OS
>
>
> On Thu, Aug 8, 2024 at 2:20 PM Neil Madden <[e-mail]>
> wrote:
>
>> Maybe I’m missing something, but all of the disclosures are covered by
>> the SD-JWT signature and so (a) are protected, and are (b) immutable.
>>
>> — Neil
>>
>> On 8 Aug 2024, at 19:18, Orie Steele <[e-mail]> 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".
>>
>> 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.
>>
>> That is very similar to the kind of unprotected header processing that
>> COSE supports, see:
>>
>> https://www.rfc-editor.org/rfc/rfc9338.html#section-2
>>
>> Sure maybe it's less obvious that jwt (cnf) -> disclosures -> hash -> kbt
>> signed by cnf is a kind of counter signature.
>>
>> But it is a second signature, over a specific set of disclosures that is
>> grouped together with the first signature, which are verified together.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-10#section-9.1
>>
>> """
>> Unprotected headers other than disclosures are not covered by the digest,
>> and therefore, as usual, are not protected against tampering.
>> """
>>
>> This is similar to how values in unprotected headers in COSE are not
>> protected, unless there is some "verification process" such as checking a
>> counter signature, or merkle tree inclusion proof.
>>
>> 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.
>>
>> OS
>>
>>
>>
>>
>>
>> On Thu, Aug 8, 2024 at 12:33 PM Brian Campbell <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> On Thu, Aug 8, 2024 at 11:27 AM Orie Steele <[e-mail]>
>>> wrote:
>>>  <snip>
>>>
>>>>
>>>> If JWTs had unprotected headers, I suspect SD-JWT would have used them
>>>> for the mutable part (disclosures).
>>>>
>>>
>>> That suspicion is entirely incorrect.
>>>
>>> <snip>
>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>
>>
>>
>> --
>>
>> ORIE STEELE
>> Chief Technology Officer
>> www.transmute.industries
>> <https://transmute.industries/>
>> _______________________________________________
>> jose mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>