On Mon, May 6, 2024 at 11: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. > For the record - that particular note was added to the FAPI 2.0 Security Profile draft not as a mitigation for the existence of a polymorphic algorithm identifier but rather as a workaround for the anticipated problem that this draft-ietf-jose-fully-specified-algorithms introduces with the prospective registration of a new algorithm identifier that FAPI needs to account for. > > > 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. > I might humbly suggest that the prospective updates, while perhaps mostly editorial, are fairly fundamental to the content of the draft itself and should be applied to the draft prior to (a new) WGCL. Resolving the draft's many outright self-contradictory statements would likely go a long way towards avoiding feedback at the level of "this draft is still deeply confused and not anywhere near ready for publication" and facilitate a more productive last call cycle that's a better use of everyone's time. > > -- 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] > -- _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]
