Hi John,
We updated the RSA description in the draft to incorporate your and others'
feedback. See
https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-06.html.
We also added Security Considerations text about providing the "alg" value in
keys.
Thanks again,
-- Mike & Orie
From: John Mattsson <[email protected]>
Sent: Wednesday, September 18, 2024 11:09 PM
To: Orie Steele <[email protected]>; cose <[email protected]>; JOSE WG
<[email protected]>
Subject: [COSE] Re: Fully Specified Keys and
draft-ietf-jose-fully-specified-algorithms
Hi Orie,
>In JOSE and COSE, we use "alg" to "restrict a key to a specific algorithm".
Yes, but "alg" in both COSE_Key and JWK is OPTIONAL, and I don't think there
are any security considerations. If you agree, and the draft is about security,
I think it would good if the draft shortly discussed why "alg" in COSE_Key and
JWK is a good thing and recommended that it is present, unless using the same
key for different algs has been proven secure. https://eprint.iacr.org/2021/509
>Is your proposal to have RSA parameters be considered part of RSA algorithms?
I was not proposing much at all. I just provided more details on why
"This is not a problem in practice, because RSA libraries accommodate keys of
different sizes without having to use different code."
is not correct in general, which also Neil Madden pointed out. I am fine with
just removing the above sentence or adding changing to "because COSE and JOSE
RSA libraries" if there is data to back that up.
>Let's set aside any potential registry updates for a moment.... Knowing what
>we >know now, regarding interoperability, and parameter errors, and best
>practices for >using cryptographic keys, wouldn't we fully specify RSA keys
>and algorithms, if we >could?
Yes.
>If you had a fully specified RSA algorithm identifier, and you used that
>>identifier in an RSA key... wouldn't that make the RSA key fully specified?
Yes. Actually I think the current RSA algorithms identifiers would do as the
domain parameters are already in the key.
>The high level goal of the draft is to ensure that if 2 parties say they
>support >an algorithm identifier, that is all they need to ensure they can
>interoperate.
That was my understanding as well. But there does not seem to be agreement
regarding this:
"I disagree with your statement that the draft is about interoperability, not
security."
https://mailarchive.ietf.org/arch/msg/jose/J7KC750Ka-73V-eYt957DX2ymIs/
Cheers,
John (as an individual)
From: Orie Steele <[email protected]<mailto:[email protected]>>
Date: Wednesday, 18 September 2024 at 19:12
To: cose <[email protected]<mailto:[email protected]>>, JOSE WG
<[email protected]<mailto:[email protected]>>
Cc: John Mattsson
<[email protected]<mailto:[email protected]>>
Subject: Fully Specified Keys and draft-ietf-jose-fully-specified-algorithms
John,
Regarding your last comment in:
https://mailarchive.ietf.org/arch/msg/cose/eRn8vShjqW83JEGXwIVjzrIyA4M/
> For security purposes fully-specified keys are likely much more important
> than fully specified algorithms.
In JOSE and COSE, we use "alg" to "restrict a key to a specific algorithm".
Is your proposal to have RSA parameters be considered part of RSA algorithms?
Let's set aside any potential registry updates for a moment.... Knowing what we
know now, regarding interoperability, and parameter errors, and best practices
for using cryptographic keys, wouldn't we fully specify RSA keys and
algorithms, if we could?
If you had a fully specified RSA algorithm identifier, and you used that
identifier in an RSA key... wouldn't that make the RSA key fully specified?
The high level goal of the draft is to ensure that if 2 parties say they
support an algorithm identifier, that is all they need to ensure they can
interoperate.
I would consider failing to interoperate based on different RSA parameters not
being supported on both sides, in the same category as failing to interoperate
based on different edwards curves not being supported on both sides (EdDSA in
JOSE and COSE)... or failing to interoperate based on different p curves being
supported on both sides (ES256 in COSE ... not in JOSE).
... or in a nightmarish future where we encoded custom curve parameters
directly into JWKs, and those curve parameters did not match on both sides, or
one side implemented support for custom parameters differently... see also
curveball:
https://thomasandolf.medium.com/what-is-cve-2020-0601-aka-curveball-and-why-is-it-so-dangerous-8664f8c8e9e9
<https://thomasandolf.medium.com/what-is-cve-2020-0601-aka-curveball-and-why-is-it-so-dangerous-8664f8c8e9e9>
If we agree there is an interoperability problem for EdDSA and RSA, we don't
need to solve them both the same way (or even solve them at all).
The primary mission of the document is to ensure we do not create such
interoperability or security problems in the future.
The primary mission is accomplished with new guidance to designated experts.
The secondary mission is to allow for implementations that need to resolve
these interoperability problems that exist today to do so.
The secondary mission can be accomplished with new registry entries, if and
only if, the working groups consider it to be "worth it".
If folks considered EdDSA to be worth it, and RSA to be "not worth it", I
wouldn't object to that...
But I would object to an inconsistent definition of parameters and their
relationship to fully specified algorithms... we don't want to set up future
curveball attacks on lattice or unbalanced oil and vinegar signature schemes
and their associated keys, by allowing for parameters to differ for the same
algorithm identifier.
OS
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>
[Image removed by sender.]<https://transmute.industries/>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
