I support Mike’s position and the publication of the document. > On May 6, 2024, at 10:11 AM, Michael Jones <[email protected]> > wrote: > > The draft is solving a real problem that’s not hypothetical. Multiple > specifications by multiple working groups across both JOSE and COSE have had > to create workarounds for the problems that polymorphic algorithm identifiers > are causing. While previously discussed on-list and in the draft, as a > reminder, these specifications implemented or need mitigations for > polymorphic algorithm identifiers: > > WebAuthn > <https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-public-key-easy> > contains this de-facto algorithm definition to work around this problem: > > -8 (EdDSA), where crv is 6 (Ed25519) > > FAPI 2 > <https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html#section-5.4> > contains this similar workaround: > Note: As of the time of writing there isn't a registered > <https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms> > fully-specified algorithm describing "EdDSA using the Ed25519 variant". If > such algorithm is registered in the future, it is also allowed to be used for > this profile. > > OAuth 2.0 Authorization Server Metadata > <https://www.rfc-editor.org/rfc/rfc8414.html#section-2>, which defines this > metadata property (and others similar to it): > token_endpoint_auth_signing_alg_values_supported > OPTIONAL. JSON array containing a list of the JWS signing > algorithms ("alg" values) supported by the token endpoint for the > signature on the JWT [JWT > <https://www.rfc-editor.org/rfc/rfc8414.html#ref-JWT>] used to authenticate > the client at the > token endpoint for the "private_key_jwt" and "client_secret_jwt" > authentication methods. > > OpenID Connect Discovery 1.0 > <https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>, > which defines this metadata property (and others similar to it): > id_token_signing_alg_values_supported > REQUIRED. JSON array containing a list of the JWS signing algorithms (alg > values) supported by the OP for the ID Token to encode the Claims in a JWT > [JWT] <https://openid.net/specs/openid-connect-discovery-1_0.html#JWT>. > > Neil, you’re right that the spec needs editorial work to accurately reflect > which parts of the problem space the working group decided to tackle and not > tackle at this time. We didn’t update the spec before WGLC to reflect the > outcome of the on-list working group discussion “[jose] Fully-specified ECDH > algorithms”. This will happen once the working group last call feedback is > in. That said, solving the acute parts of the problem now won’t preclude > additional specifications solving more of the pain points in the future. > > As for you disagreeing with deprecating “EdDSA” for JOSE, the polymorphic > EdDSA definition is the root cause of the need for the workarounds above. > Fixing the problem requires replacing it. > > Summarizing my position, this specification will be ready for publication > after applying the (mostly editorial) updates described above. > > -- Mike > > From: jose <[email protected] <mailto:[email protected]>> On Behalf > Of Neil Madden > Sent: Monday, May 6, 2024 6:41 AM > To: Karen ODonoghue <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms > > Unsurprisingly, I still don’t think this is a very good idea, and I think the > draft still needs a lot of work. The abstract and rest of the draft still > mentions making *all* JOSE algorithm identifiers “fully-specified”, but the > draft does no such thing: just changing EdDSA now (for JOSE). As this WGLC > says, there was no support for “fully-specifying” ECDH algorithm identifiers, > because it’s clearly a bad idea. > > So the draft needs to be substantially rewritten to reflect what it is > actually now proposing. It also, ironically, needs to flesh out what > “fully-specified” means, because that description is very vague. (eg it seems > key sizes do not need to be specified, but curves do, and it refers to KDFs > and other things that are not in scope). Perhaps rewrite it as a more > focused draft saying that *elliptic curve signature* algorithms should > specify the curve specifically. > > I strongly disagree with deprecating “EdDSA” for JOSE, so IMO section 3.1.2 > should be deleted. > > The entirety of section 3.3 should also be removed, or else substantially > rewritten to reflect that the advice doesn’t apply to encryption algorithms. > I would delete it. > > Section 6.1 is wrong, as has been pointed out already in this WG: numerous > HSM restrict RSA key sizes they support. (Saying it’s not a problem in the > wild because everything uses the same key sizes begs the question as to why > the same reasoning doesn’t apply to EdDSA). > > Section 6.2 says it is not sure what to do, suggesting the draft isn’t ready > for WGLC. > > The security considerations in section 7 are nonsense. How does an attacker > get to “choose algorithms” with current EdDSA? > > Overall, this draft is still deeply confused and not anywhere near ready for > publication. > > Regards, > > Neil > > > On 6 May 2024, at 06:31, Karen ODonoghue <[email protected] > <mailto:[email protected]>> wrote: > > JOSE working group members, > > This email initiates a three week working group last call on the following > document: > https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/ > > All open issues have been resolved. Additionally there does not appear to be > general support for including fully-specified ECDH algorithms. > https://mailarchive.ietf.org/arch/msg/jose/ZHDlXENvTwjlWxTVQQ2hkNBX4dw/ > > Please review the document and post any final comments along with your > recommendation on whether or not it is ready to proceed by the Monday 27 May. > > Thank you, > JOSE chairs > > _______________________________________________ > jose mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
