+1 Orie. I think that works well
On Sat, Nov 9, 2024, 08:48 Orie Steele <[email protected]> wrote:
> 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]
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
