On Tue, 2025-10-28 at 16:16 +0000, Paul Bastian wrote: > I think the introduction isn't perfect yet (it's an I-D), but gives good > (multiple) pointers for motivation: > > - JWS doesn't provide mechanisms for to dynamically derive MAC keys
> - the method is intended for use cases where pre-shared keys are > undesirable or infeasible How is this different than just using ECDH-ES+A256KW with ephemeral keys to transmit the data instead of "signing" it ? > - it allows HMAC signatures used in SD-JWTs mirroring capabilities from > ISO 18013-5 I still fail to understand in what situation you'd want to sign something w/o proving your identity and/or the truthfulness of the data transmitted. What's the use case here? As for ISO 18013-5, it is pay-walled so I do not know if it provides any reasonable justification or use case that applies to JWT/JWS. > For what its worth, it seems to me neither 7518, 8032 nor 8812 provide > significant justification or motivation. None of them are providing new mechanisms, just making existing ones available via a new API (JOSE). They provide extensive Normative references to justify the presence of each of those algorithms in the standards. In the draft I see these as references: - [BSI-TR-03111] referenced from Cryptographic Dependencies. This reference is not in-line with the rest of the JWT ecosystem which references instead [NIST.800-56A] - [RFC2104], [RFC5869], which are already referenced in [RFC7518] which is also a reference so kind of redundant (And [RFC7518] already references also [NIST.800-56A] form the previous point) - [RFC7515], [RFC7517], [RFC7518] which are expected. - [RFC2119] and [RFC8174] general formatting references. So nothing in the normative reference that provide me with information on the soundness or applicability of this new mechanism. The informative references cite: - [ISO-18013-5] ... paywalled, so meh. - [TLS-NOTARY] unclear why something that describes TLS an MPC verification is relevant here (it may very well be, but this draft does not really make me understand why). > However, if we need to more, likely because the draft is just sticking > existing building blocks together, then we can provide a better > introduction (e.g. explaining privacy benefits of repudiable signatures) > I also think this makes sense if we believe fully-specified algorithms > is the right direction for JOSE and most people agreed to this at IETF 123. I am not that much concerned about the "benefits" of repudiable signatures, but more on whether this is something that is useful in a JWT ecosystem, and what for, and what guarantees this mechanism provides and what guarantees this mechanism does *not* provide allowing users to understand when it is appropriate to use this mechanism and when it is not. If there are authoritative documents that clearly examine the mechanism and can be used to determine when this mechanism should and should not be used, a reference to those documents is also fine... as long as they are open access. Best, Simo. > Best, Paul > > On 10/28/25 17:00, Simo Sorce wrote: > > Thanks for the pointers, > > I think justification should be part of the draft, either in the > > abstract or through a reference if there is already another standard > > document that explains where this mechanism makes sense to be used. > > > > Additionally the Security considerations should list at least examples > > of when use of this mechanism is and is *not* acceptable. > > > > Simo. > > > > On Tue, 2025-10-28 at 15:34 +0000, Paul Bastian wrote: > > > Hi, > > > > > > the topic was already presented twice at IETF, so I will link the slides > > > here, or have a look into the video material from those sessions: > > > > > > - IETF 121: > > > https://datatracker.ietf.org/meeting/121/materials/slides-121-jose-designated-verifier-signatures-00 > > > > > > - IETF 123: > > > https://datatracker.ietf.org/meeting/123/materials/slides-123-jose-designated-verifier-signatures-for-jose-00 > > > > > > In very short: privacy through repudiation and scalability in HSM-based > > > systems through easier key derivation > > > > > > Is it possible that chairs link those drafts together in the > > > datatracker? To my knowledge and extensive search, I don't think its > > > possible for the author itself to do so? > > > > > > https://datatracker.ietf.org/doc/draft-bastian-dvs-jose/ > > > https://datatracker.ietf.org/doc/draft-bastian-jose-dvs/ > > > https://datatracker.ietf.org/doc/draft-bastian-jose-pkdh/ > > > > > > Best, Paul > > > > > > On 10/28/25 16:11, Simo Sorce wrote: > > > > On Mon, 2025-10-27 at 23:10 +0100, Karen ODonoghue wrote: > > > > > 8. Public Key Derived HMAC for JOSE > > > > > https://datatracker.ietf.org/doc/draft-bastian-jose-pkdh/ > > > > I fail to understand what is the point of this mechanism. > > > > > > > > Does anyone have more information than what is available in the > > > > abstract, which does not seem to give any good rationale about > > > > why this mechanism would be useful ? > > > > > > > > What is the point of using an ECDH exchange to derive a symmetric key > > > > to then perform a HMAC signature on a message, when the premise is that > > > > both parties must already have each other Public Keys anyway and > > > > therefore could simply apply an ECDSA signature ? > > > > > > > > Simo. > > > > > > > _______________________________________________ > > > jose mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
