On Mon, Dec 02, 2024 at 02:54:54PM -0600, Orie Steele wrote:
> https://author-tools.ietf.org/iddiff?url1=draft-reddy-cose-jose-pqc-hybrid-hpke-03&url2=draft-reddy-cose-jose-pqc-hybrid-hpke-04&difftype=--hwdiff
>
> Further comments:
>
> X-Wing is not an Elliptic Curve.
>
> X-Wing keys using OKP and (ab)using the "crv" parameter to mean "curve with
> parameters + lattice with parameters"... is something I really hope we can
> decide not to do.
It is definitely not abusing it.
The description in COSE registry is just horrible. The one from JOSE
("The subtype of key pair") is much better (but JOSE uses the misleading
"crv" codepoint.)
RFC 8037, which originally defined OKP, explicitly says that "crv" is
not restircted to elliptic curves (and this was the intention from the
very beginning). And then RFC 8152 proceeded to copy this text.
OKP is meant for presenting any kind of asymmetric keys that potentially
make sense for multiple operations, and where public and private keys
are both byte strings.
ML-KEM and X-Wing both satisfy the requirements.
>From experience from writing an JWE implementation that does not cut
corners that could hide problems (in order to test JOSE-HPKE), two
wildly different things sharing the same alg causes trouble, but two
wildly different things sharing the same kty does not.
> It would be nice to agree to use keys for algorithms, and to use AKP for
> ML-KEM and ML-DSA, and X-Wing with HPKE, and X-Wing without HPKE... and all
> of this is possible with the use of the AKP key type with fully specified
> algorithms.
Unfortunately, this does not work properly outside pure-only signatures.
With just signature prehashing, it causes "absolute disaster <...> at the
operational level".
Whereas OKP assumes that there might be multiple sensible operations
with the key, AKP assumes that there is only one operation that even
makes sense.
Neither ML-KEM nor X-Wing satisfies this requirement, because both
make sense for key agreement with and without key wrapping. And those
count as differnt operations in COSE/JOSE.
But pure-only ML-DSA does satisfy it: There is only one sensible
operation, which is pure signature.
> It does not matter how many times I read the note above, the normative MUST
> says:
>
> o The parameter "crv" MUST be present and contain the subtype of the
> key (from the "JSON Web Elliptic Curve" registry).
>
> This means we are required to put things that are not curves in a registry
> for curves....
Yeah, putting two different things into one registry can get confusing.
> If the algorithm param "alg" is not mandatory for an X-Wing key, can I use
> the same key for ML-KEM and X25519 and X-Wing?
> Do I have to put "alg" in the key, even though it's optional (in OKP) to
> signal a safer use pattern?
> If I encrypt with X25519 to an X-Wing key that has no "alg" parameter, what
> happens?... is it ok, if I use the X25519 component to decrypt? it works...
> is this legal?
>
> Even if the same private key can decrypt messages to each public key that
> contains "somewhere (no validation)" the necessary components....
> The thumbprint for a hybrid public key should include the algorithm used to
> construct the hybrid, not just the public keys used with any component
> algorithms or the hybrid.
All these issues are consequences of making a distinction between hybrid
and non-hybrid algorithms.
The only code that should be aware of relation between ML-KEM, X25519
and X-Wing is low-level X-Wing implementation.
So it is impossible to "encrypt with X25519 to an X-Wing key". Even if
bad COSE/JOSE implementation allows ECDH-ES with X-Wing key (doing the
obvious thing).
> Either we should scrap the AKP concept and use OKP as Ilari suggested.
> ... or we should not use OKP for new "subtype"s... and especially not for
> hybrids.
My position is to use both for intended purpose.
ML-KEM/X-Wing is what OKP is intended for.
Pure-only ML-DSA is what AKP is intended for.
> I don't know if this comment should gate working group adoption, but it
> certainly seems it should gate a WGLC for either document that references
> ML-KEM / ML-DSA .
> Thanks to Russ, Neil and others who gave WGLC feedback on AKP and ML-DSA
> for JOSE and COSE, I am tracking your comments here:
> https://github.com/cose-wg/draft-ietf-cose-dilithium/issues but have not
> yet addressed them.
>
> Ilari, Hannes and Tiru, please feel free to file a WGLC comment on the use
> of AKP in ML-DSA.
As far as I can see, the existing comments cover the issues. I don't see
kind of issues where reasonable-looking way ends up hitting some subtle
issues.
> Whatever the outcome, there should be alignment on seeds, private keys,
> public keys and algorithms for lattice and hybrid PQC (ML-DSA / ML-KEM /
> X-Wing)
>
> "pub" is better than "x"
>
> "priv" is better than "d"
>
> "alg" should have been mandatory in keys,
> ... and forbidden in headers ( a ship that has sailed, and can't be fixed
> for EC2 / OKP keys, or JWE / COSE Encrypt envelopes )...
ML-DSA and ML-KEM are very different things. And the only precdent for
anything like ML-DSA in COSE/JOSE is EdDSA.
And making "alg" mandatory in keys and forbidden in headers would have
required design different from how JOSE did it (and COSE copied those
parts of the design).
> *...things that are not elliptic curves do not belong in a registry for
> elliptic curves...*
>
> I will die on these hills. If I'm in the rough, it would be good to know.
I have considered an idea of trying to fix the OKP mess to the extent
possible (I think the only thing that can't be fixed is the "crv"
codepoint in JOSE). At least splitting the registeries and fixing the
descriptions.
-Ilari
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
