On Fri, Aug 9, 2024 at 2:00 AM Neil Madden <neil.e.mad...@gmail.com> wrote:
> > > On 8 Aug 2024, at 23:34, Orie Steele <orie@transmute.industries> wrote: > > On Thu, Aug 8, 2024 at 3:26 PM Neil Madden <neil.e.mad...@gmail.com> > wrote: > >> >> >> On 8 Aug 2024, at 20:44, Orie Steele <orie@transmute.industries> 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. > > > What security property do you think is being violated here? > I'm just describing how SD-JWT works. My point is that this part is similar to how COSE Sign1 works as well. In COSE Sign1 the unprotected header is also unordered, and not integrity protected. > > 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). > > > This is not what unsecured means. > ok, perhaps I should have said "unprotected". > > > 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. > > > This is trivially possible in any signature/MAC scheme: the crypto detects > modifications it doesn’t prevent them. > > With apologies to Lea Kissner: cryptography is a tool for turning > confidentiality and integrity threats into denial of service threats. > I completely agree with this point. > > > 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. > > > I’m not sure what you’re arguing here. There are things you have to do to > validate any signature scheme. If you don’t do them, the security > properties don’t apply. (If you want to discuss more misuse-resistant APIs, > we can do that). > I'm not arguing for a change to SD-JWT or COSE Sign1, I am explaining how they both use unprotected information together with protected information. > > 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. > > > I don’t think this follows at all from your arguments. > Since COSE and JSON Serialized SD-JWT support unprotected headers, which are an extensibility point, but compact SD-JWT does not support unprotected headers, a better design for JWP would allow unprotected headers in both compact and json serializations, or there would be just 1 serialization, and it would support unprotected headers. The reason I think this is an improvement is that it keeps supported features aligned between JOSE and COSE, so there is no reason to pick 1 over the other except for in relation to serialization readability, complexity, and size. POST https://verifier.example/ content-type: application/jwp or application/jwp+json // both can contain unprotected stuff POST https://verifier.example/ content-type: application/cwp // can contain unprotected stuff I'll argue the opposite to see if you agree with that position: JWP should be like JWE/SD-JWT, it should not have an unprotected header in compact serialization, but should have an unprotected header in JSON Serialization, implementations that start with compact serialization but need unprotected stuff, will either need to switch to json serialization, or transport the unprotected stuff in a different part of the protocol, for example: POST https://verifier.example/ content-type: application/sd-jwt+json // contains unprotected stuff POST https://verifier.example/?unprotected-stuff content-type: application/sd-jwt // no unprotected stuff POST https://verifier.example/ content-type: application/cwp // can contain unprotected stuff In summary: 2 media types would be better than 3. If there are 3 media types, there should not be major extensibility / interoperability differences in just 1 of them (the compact one). If compact serialization supported unprotected headers, I think it's less likely that jades would have done what it did... and the need for a JSON serialization is reduced, and I would support deferring its specification to some future document, when there is a need for it. > > — Neil > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
