Hi Mike,
Thanks for the response, but none of this addresses or is even relevant to any
of the points I raised. It just confirms that the mistake is wide-spread.
Taking OIDC as an example, why is it a perfectly fine solution for OIDC
discovery to define both
id_token_encryption_alg_values_supported
id_token_encryption_enc_values_supported
allowing these two independent parameters to be independently specified, but it
is not an option to define a similar
id_token_encryption_crv_values_supported
?
Incidentally, given that you've put WebAuthn in the list, what's the plan there
for when you deprecate the algorithm identifiers used by already deployed
hardware? Given that WebAuthn is basically a monoculture around ES256 at this
point, you will be directly deprecating the algorithm used by nearly 100% of
existing hardware.
(I tried to find out *why* WebAuthn makes this restriction instead of just
specifying the key size/curve directly, but I got lost in a maze of twisty
little hyperlinks, all alike).
-- Neil
On 6 May 2024, at 18:11, 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]
> <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/
> <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/
> <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
> <https://www.ietf.org/mailman/listinfo/jose>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
