I did read a prior version of the document and found it generally in good shape. I support its publication. Due to various life and work circumstances (including a chronic inability to effectively manage my own time, exacerbated by the recent loss of a parent and all that comes with) I have not had the chance to do a proper review of the latest nor is that likely to by 30 June. But I trust that both Filip and Neil have only improved the draft from that place of being in pretty good shape already.
On Wed, Jun 24, 2026 at 3:36 PM Karen ODonoghue <[email protected]> wrote: > Thank you Filip. > > To remaining jose working group members, please review and comment on this > document by 30 June. I’m giving you one more short extension. The document > is very short, and we adopted it as a working group document. Now that we > are at this stage, we really should show consensus to publish it. > > Thanks. > Karen > > On Jun 25, 2026, at 4:56 AM, Filip Skokan <[email protected]> wrote: > > With -05 out on the datatracker I support publication. > > S pozdravem, > *Filip Skokan* > > > On Wed, 17 Jun 2026 at 11:30, Filip Skokan <[email protected]> wrote: > >> Thank you Neil, I've updated the PR to reflect your comments and included >> the offered changes. >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Wed, 17 Jun 2026 at 11:17, Neil Madden <[email protected]> >> wrote: >> >>> Thanks Filip, responses inline below. >>> >>> On 17 Jun 2026, at 08:03, Filip Skokan <[email protected]> wrote: >>> >>> >>> I believe some further work in due: >>> >>> This PR >>> <https://github.com/NeilMadden/jose-deprecate-none-rsa1_5/pull/10> >>> addresses the following minor finds: >>> >>> - `The 'none' algorithm`, `The 'RSA1_5' algorithm`, and `Guidance on >>> deprecation` promoted from H2 subsections of the Introduction to >>> top-level >>> (H1) sections >>> - anchored the `none` section (`{#none}`) and replaced `Sec. 1.1` in >>> Security Considerations with `{{none}}` (auto-tracked section number) >>> - `{{RFC8017}} (section 7.2)` → `{{Section 7.2 of RFC8017}}`; >>> `Section 7.1 of {{RFC7518}}` → `{{Section 7.1 of RFC7518}}` >>> - `[OpenID.Core]` → `{{OpenID.Core}}` (single brackets don't render) >>> - `applictions` → `applications` >>> - "currently lists 12" → "At the time of writing it lists 17" >>> >>> These all look good, I will apply the PR later. Thank you. >>> >>> Remaining finds: >>> >>> - Inconsistent algorithm-name formatting: `"none"`/`"RSA1_5"` vs. `` >>> `none` ``/`` `RSA1_5` ``. Pick one. >>> - `{{I-D.irtf-cfrg-rsa-guidance}}` is IRTF/CFRG (Informational, -08, >>> in IRSG poll) and targets "any deployments or protocols", "for IETF >>> protocols" is slightly off; "for new protocols and deployments" would be >>> more accurate. >>> - Lowercase "should" with `bcp14-tagged` enabled is ambiguous; >>> capitalize or rephrase per instance >>> - "MUST disable support for these algorithms by default" vs. "can >>> continue to do so": make the opt-in allowance explicit; tie to RFC 7518 >>> §3.6 "MUST NOT accept Unsecured JWSs by default" >>> >>> >>> Will fix these ones, thanks. >>> >>> >>> - IANA DE Instructions: IND-CCA2 scope too narrow; The `alg` >>> category spans key encryption, key wrapping, ECDH-ES, key-agreement+wrap, >>> and `dir`. IND-CCA2 fits PKE/KEMs, not all of the others. Scope the >>> criterion to key-encryption/KEM `alg`s (and align with the PQ & PQ/T >>> work <https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-pq-pqt/> >>> ). >>> >>> >>> Thanks, this is a good point to raise. Most of the algorithms in those >>> categories can meet some definition of IND-CCA2. There are different game >>> definitions for some of them, but it’s not a notion that only applies to >>> PKE. For example, there is a well-known result that symmetric authenticated >>> encryption implies CCA2 security. >>> >>> ECDH-ES perhaps needs some thought, as it doesn’t fit easily and also >>> has “benign malleability”, which would technically make it non-CCA, but I >>> think a JWE as a whole would be - as the ephemeral key is in the protected >>> header. (There are IND-CCA2 proofs for variants of ECIES, which is what >>> ECDH-ES is, but they probably don’t directly apply here). >>> >>> I think probably the simplest fix here is to update the instructions to >>> say that the IND-CCA2 goal applies to the entire JWE encryption process, >>> not to just the key management algorithm on its own. >>> >>> On the other hand, the odd cases like ECDH-ES can be viewed as >>> historical. These days you’d register that as a KEM (DH-KEM) and meeting >>> IND-CCA2 would be unproblematic. As a minimum bar, it still seems the right >>> choice to me. >>> >>> >>> - IANA DE Instructions: There's subtlety in the EUF-CMA one. A MAC >>> is not a digital signature, and JOSE is deliberate about that >>> distinction. A Designated Expert reading the instruction literally could >>> conclude the EUF-CMA bar doesn't apply when someone registers a new MAC. >>> >>> Good catch - I will reword to “JWS signature and MAC algorithms”. >>> >>> Furthermore, there are WICG documents being incubated that will do >>> register a number of "JSON Web Signature and Encryption Algorithms" IANA >>> Registry "alg" values for JWK Usage only (i.e. they don't define a JWS or >>> JWE algorithm but allow key representation for Web Cryptography APIs needs) >>> - those would not be possible with the proposed DE instructions. I >>> recommend further scoping the updates by Usage Location and stating that >>> JWK-only registrations stay governed by the general RFC 7518 §7.1 rule. >>> >>> >>> The DE instructions are already scoped to “JWS algorithms”/“JWE key >>> management algorithms” etc. I don’t think they would prevent JWK-only >>> registrations. I’d be happy to add some additional text if you think it’s >>> not clear. >>> >>> >>> I offer to submit a PR for these too. >>> >>> >>> Many thanks! >>> >>> Neil >>> >> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _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._
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
