Hello Orie, (adding JOSE cc)
I am supportive of defining AKP semantics for seed vs private key forms, but I would like to know whether to align fully with LAMPS in terms of expanded, seed, or both is necessary. It is entirely possible that's a discussion that happened and I am not aware of it, in which case I apologize. I can imagine a JWK representation restricted to just the following combinations would work just fine as well and would lead to less edge cases to be handled by users and libraries - kty, alg, and seed (pub missing, priv missing; not required given a seed is present, no consistency checks required) - kty, alg, and pub - kty, alg, priv and pub (seed missing) Interested in what you think? Are we just patching an almost done piece of work at this moment? Or is there a moment to step back and come up with a clean setup given the LAMPS outcome. S pozdravem, *Filip Skokan* On Tue, 25 Mar 2025 at 17:34, Orie <[email protected]> wrote: > Hi, > > https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16 > > As discussed at IETF 122, I have raised this pull request to track the > changes anticipated in the LAMPs WG. > > As I was not able to attend either session, I would greatly appreciate > reviews / comments, to ensure this PR is heading in the right direction. > > I've made some adjustments to the parameter names, and added some > normative guidance text, to ensure that the allowance of multiple key > parameters for private information classes is not an invitation for future > registrations to follow this pattern. > > I'm including our ADs since this document is already in AD Evaluation, and > the draft-ietf-lamps-dilithium-certificates document authors for visibility. > > Regards, > > OS > > _______________________________________________ > 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]
