On 2020-09-19 06:01, Benjamin Kaduk wrote:
Hi Anders,
Hi Ben,
First off, this is just a comment to a Request For Comments :),
not a change request.
[The quoting seems to have gotten messed up; IIUC the context was the
following]
- In general, using the same key with multiple algorithms is not
cryptographically safe. There can be algorithm pairs which interact
badly (for instance, Ed25519 and the original Ed25519ph).
There is absolutely no disagreement with that but the rationale was as
I understand to make it more difficult to violate the above. However,
this was not done for "EC" keys so it was effectively another strategy
within the same standard. That MAY be called "quirk" in the same vein
as the multiple ways of representing binary data in JWS is.
On Thu, Sep 17, 2020 at 07:02:09AM +0200, Anders Rundgren wrote:
Apparently the PKIX folks came to a different conclusion:
https://tools.ietf.org/html/rfc8410#section-3
"The same algorithm identifiers are used for identifying a public key,
a private key, and a signature (for the two EdDSA related OIDs)."
I'm not seeing how that's inconsistent with one-algorithm-per-key -- you
know from the context in which the OID appears whether you have a
signature, public, or private key, and that context is used to namespace
the following algorithm lookup. Accordingly, there is no ambiguity as to
what the OID means, in that context.
What I was trying to say, is that I find the PKIX naming more logical than
8037. It is also aligned with Java 15/JCE which doesn't accept "EdDSA" as
a signature algorithm; it only understands Ed25519 and Ed448.
This became obvious in my JWS "remake" (JSF) where I adopted the PKIX
algorithm and key naming scheme:
{
"statement": "Hello signed world!",
"otherProperties": [2e+3, true],
"signature": {
"algorithm": "Ed25519",
"value":
"nhYLrEcJV60sEG1RfZGrylL7oVvby1eNRMVzKn-ei93HrXq27e1bqsJpk0rkKg-l9TzTchPFigGt5QbVYirSBw"
}
}
Using EdDSA as algorithm in the example above would IMO look a bit strange.
Personally, I would also have considered using "EdDSA" and "ECDH" as "kty"
arguments rather than the somewhat esoteric "OKP" solution, but in the end
it all boils down to the quality of the library or application which should
be prepared for incorrect in-data.
I didn't follow this development when it was active because I wasn't ready
to take on curve25519 and curve448 since Oracle have taken EONS of time
to define the associated API. It will finally be released this month!
Anders
-Ben
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
