As a co-editor of FAPI2, yes this is a real problem.
I think that having a spec like this would be beneficial and I support
publication.
I would, however, like to see the editorial points raised by Neil being
addressed.
-Daniel
Am 06.05.24 um 19:11 schrieb Michael Jones:
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]
