Others had also suggested something along the lines of
“id_token_encryption_crv_values_supported”, but the problem is that that’s
playing a game of whack-a-mole. Yes, if the missing information to make an
algorithm fully-specified is a curve, then this helps. But cryptographers are
clever (a good thing!) and regularly come up with new ways of parameterizing
cryptographic functions. Parameters include hash functions, key derivation
functions, mask generation functions, curves, and more. We could either keep
adding ad-hoc metadata parameters for each new kind of parameterization that
arises or we can use fully-specified algorithms. The fully-specified
algorithms approach works with all current parameterizations *and* all the new
creative parameterizations that cryptographers will invent in the future and so
is future-proof, unlike the keep-adding-metadata-parameters-as-needed approach.
Obviously, hardware will and software can keep using deprecated algorithms as
long as they choose if they continue to meet a need. (Heck, we even registered
the deprecated RSA-SHA-1 for COSE because TPMs use it!). That’s reality. But
registering fully-specified algorithms gives future software and hardware the
opportunity to unambiguously use the full range of pertinent algorithms –
something that’s problematic today, per my previous note.
-- Mike
From: Neil Madden <[email protected]>
Sent: Monday, May 6, 2024 11:58 AM
To: Michael Jones <[email protected]>
Cc: Karen ODonoghue <[email protected]>; JOSE WG <[email protected]>
Subject: Re: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms
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]<mailto:[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]
