AKP seems fine to me, for example:
const jwk = {
kty: "AKP",
kid: "01",
alg: "X-Wing",
pub: "4iNrNajCSz...tmrrIzQSQQO9lNA", // both public keys
priv: "f5wrpOiP...rPpm7yY", // single seed
key_ops: ["deriveBits"],
};
See the key generation here:
https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-06#appendix-B.1
Especially this part:
def GenerateKeyPairDerand(seed):
assert len(seed) == 32
skM, skX, pkM, pkX = expandDecapsulationKey(seed)
return seed, pkM + pkX
OS
On Sat, Nov 9, 2024 at 7:41 AM Ilari Liusvaara <[email protected]>
wrote:
> On Fri, Nov 08, 2024 at 09:30:39PM +0000, Orie Steele wrote:
> > You can use the AKP key type registered in ML-DSA draft, and just define
> > the pub and priv parameters as concatenations, or you can use the same
> seed
> > value for private key, and the public keys as concatenated.
>
> AKP is not suitable here, because AKP assumes that the the key only
> makes sense in one algorithm, and this draft already violates the
> assumption. Furthermore, all KEMs turn out to make sense in multiple
> algorithms, so AKP is not suitable for any KEM keys.
>
> The proper existing key type for KEMs with byte string I/O (e.g.,
> X-Wing) is OKP, as there is no present key type specific to HPKE.
>
> Furthermore, HPKE forces byte string I/O anyway, so I would like that
> there would not be another legacy format hack (besides the EC/EC2 one).
>
>
> > On Fri, Nov 8, 2024, 5:41 PM Ilari Liusvaara <[email protected]>
> > wrote:
> >
> > > On Fri, Nov 08, 2024 at 03:04:22PM +0000, Michael Jones wrote:
> > > > Per discussions at the IETF 121 COSE working group meeting, this note
> > > > starts a two-week call for adoption of the PQ/T Hybrid KEM: HPKE with
> > > > JOSE/COSE specification. Please let us know whether you are in favor
> > > > of adoption or not by Friday, November 22, 2024.
> > >
> > > What KEM is the draft supposed to use?
> > >
> > > It references something called "X25519MLKEM768 Hybrid KEM", which is
> > > not found in HPKE KEM registry, nor seems to be pending addition to it.
> > >
> > > Is that supposed to be X-Wing (HPKE KEM id 0x647a)? That is a hybrid of
> > > X25519 and ML-KEM 768. If so, the algorithm name should presumably
> > > reference "xwing" instead.
> > >
> > > The draft should explicitly specify the HPKE KEM/KDF/AEAD id values to
> > > use. HPKE absolutely requires any KEM/KDF/AEAD used to be in its
> > > registeries.
> > >
> > >
> > > Also, the draft should register the keys required, something like:
> > >
> > > - COSE Elliptic Curves:
> > >
> > > * Name: X-Wing
> > > * Value: <TBD>
> > > * Key type: OKP
> > > * Description: X-Wing
> > > * Change Controller: IESG
> > > * Reference: <self>
> > > * Recommended: <TBD>
> > >
> > > - JSON Web Key Elliptic Curve:
> > >
> > > * Curve name: XWing
> > > * Curve description: X-Wing key pairs
> > > * JOSE Implementation Requirements: <TBD>
> > > * Change Controller: IESG
> > > * Reference: <self>
> > >
> > > (Yes, the terminology is utterly confusing. Trying to fix it to the
> > > extent possible is a topic for another RFC.)
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
