Likewise, I support Mike Jones's position and forward movement/publication of the document.
Mike Prorock founder - mesur.io On Mon, May 6, 2024, 11:59 Gabe Cohen <[email protected]> wrote: > 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]> *On Behalf Of *Neil Madden > *Sent:* Monday, May 6, 2024 6:41 AM > *To:* Karen ODonoghue <[email protected]> > *Cc:* [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]> 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] > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > 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]
