Agreed. Chair hat off, I'd like to understand whether the Lamps rationale for
supporting both public key formats applies to JOSE and COSE in practice. My
understanding was that Lamps decided to do that because of HSMs that were
already supporting X.509 signatures using the expanded private key format.
That doesn't seem pertinent to JOSE or COSE.
I we can keep one private key representation, that will improve
interoperability long term.
-- Mike
From: Filip Skokan <[email protected]>
Sent: Thursday, March 27, 2025 9:44 AM
To: Orie <[email protected]>
Cc: [email protected]; [email protected];
[email protected];
[email protected]; JOSE WG <[email protected]>
Subject: Re: [COSE] draft-ietf-cose-dilithium-05 add support for priv_exp
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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
