On 2023-08-30 9:10, Ilari Liusvaara wrote:
On Wed, Aug 30, 2023 at 01:27:49AM +0000, Michael Jones wrote:
Orie Steele<https://twitter.com/OR13b> and I have written a new
specification creating algorithm identifiers for JOSE and COSE that
fully specify the cryptographic operations to be performed -
something we'd promised to do during our presentation to the JOSE
working
group<https://datatracker.ietf.org/meeting/117/materials/slides-117-jose-fully-specified-algorithms-for-jose-and-cose-00>
at IETF 117. The introduction to the specification (quoted below)
describes why this matters.
The specification is available at:
*
https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-00.html
Two small things that came up in quick read:
- Why ES25519/ES448 instead of Ed25519/Ed448? Or is having an alg and
crv with the same name an issue for some implementations?
I would associate ES25519/ES448 with certain other stuff...
- Ed25519 and Ed448 are fully specified algorithms, so the description
field could just be "Ed25519"/"Ed448".
Indeed. I adopted this for JSF (JSON Signature Format):
{
statement: "Hello Signed World!",
otherProperties: [2000, true],
signature: {
algorithm: "Ed25519",
publicKey: {
kty: "OKP",
crv: "Ed25519",
x: "_kms9bkrbpI1lPLoM2j2gKySS-k89TOuyvgC43dX-Mk"
},
value:
"exZXFA5-7nwVc4xX15B95Vd3aXW_8iGOZin8hcxoyUZAAULqKb7wazzocKuhRT0HfeZqFZxgDZteztXTQ7TUCw"
}
}
It seems that https://www.rfc-editor.org/rfc/rfc8410 builds on the same idea.
Anders
Then:
"Discuss the treatment of EDCH-ES and its ephemeral keys."
There is actually an related issue in JOSE and COSE.
ECDH-ES (and ECDH-SS) when appiled to EC/EC2 keys is non-cofactor, which
makes it unsuitable for curves with h > 1. X25519 and X448 have built-in
workaround.
Currently, there are no curves that trigger the problem. However, there
are proposals to register curves that do.
There are essentially two ways to address this:
- Define copies of existing ECDH-ES/ECDH-SS codepoints that are limited
to EC/EC2 and multiply by h at output.
- Change the existing codepoints to multiply by h at output for EC/EC2.
The issue with latter is if somebody is using ECDH-ES/ECDH-SS with some
private EC crv that happens to have h > 1. That would create an
incompatibility.
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
